General Disclaimer 


One or more of the Following Statements may affect this Document 


• This document has been reproduced from the best copy furnished by the 
organizational source. It is being released in the interest of making available as 
much information as possible. 


• This document may contain data, which exceeds the sheet parameters. It was 
furnished in this condition by the organizational source and is the best copy 
available. 


• This document may contain tone-on-tone or color graphs, charts and/or pictures, 
which have been reproduced in black and white. 


• This document is paginated as submitted by the original source. 


• Portions of this document are not fully legible due to the historical nature of some 
of the material. However, it is the best reproduction available from the original 
submission. 


Produced by the NASA Center for Aerospace Information (CASI) 



9 



\ 


& 


-h 


ENBiHCEnEBTS^AN!) GE» 

Pinal Report (BcoSu-Sonala^'f*®® 

Co.) gg p A05/HP iQi ^las Astronautics 

CSCL 09B 

G3/61 27947 









/ 


O' 

/VfOOO/V/Vf 1.1. V- 


DOUGLAS 


META ASSEMBLER ENHANCEMENTS AND 
GENERALIZED LINKAGE EDITOR 
(CONTRACT NAS8-32570) 

Final Report 

JUNE 1979 MDCG8027 


PREPARED FOR: 

GEORGE C. MARSHALL SPACE FLIGHT CENTER 
MARSHALL SPACE FLIGHT CENTER 
ALABAMA 35812 


PREPARED BY: 

MCDONNELL DOUGLAS ASTRONAUTICS CO-WEST 
AVIONICS CONTROL AND INFORMATION SYSTEMS 
HUNTINGTON BEACH, CALI FORNIA 92647 


MCDO/V/SIELL DOUGLAS ASTRONAUTICS CORIRANT- HUNTINGTON BEACH 


5301 Bolsa Avenue. Huntington Beach, CA 9264 7 





PREFACE 


The final report for "Meta Assembler Enhancements and Generalized Linkage 
Editor" is submitted to the National Aeronautics and Space Administration, 
George C. Marshall Space Flight Center in accordance with the provisions of 
the contract number NASS-32570. The report describes the results of the 
design and implementation of an enhanced meta assembler and generalized 
linkage editor to provide syntax responsive and target reconfigurable 
assembly, linkage edit and library creation and maintenance capability. 

If any additional information is desired, please contact any of the following 
McDonnell Douglas or NASA representatives as appropriate: 

Mr. Z. Jelinski, Project Manager (MDAC) 

Huntington Beach, California 
Telephone: 714-896-5060 

Mr. K. V. Smith, Principal Investigator (MDAC) 

Huntington Beach, California 
Telephone: 714-896-2937 

Mr. Geoffrey C. Hintze, Project COR (NASA) 

Marshall Space Flight Center, Alabama 
Tel ephone : 205-453-5709 
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Section 1 
INTRODUCTION 

McDonnell Douglas Astronautics Company-West (MDAC-W) has developed a Meta 
Assembler for NASA under previous contract efforts. Under contract NAS8-27202 
the initial development of the Meta Assembler for the SUMG was performed. 

The capabilities included assembly for both main and micro level programs. 
Contract NAS8-30907 provided support to NASA MSFC during a period of checkout 
and utilization to verify the performance of the Meta Assembler. Under 
contract NASI 0-8434 and NASI 0-8833 additional enhancements were made to the 
Meta Assembler which expanded the target computer family to include archi- 
tectures represented by the PDP-11, MODCOMP II, and Raytheon 706 computers. 

1.1 PROBLEM STATEMENT 

In spite of its usefulness, the system had some serious shortcomings namely 
the Meta Assembler used a language independent syntax for directives (pseudo 
ops), macros and labels because these features could differ g”eatly from one 
assembly language to another. For this reason, existing assembly language 
programs had to either have the source for these differences rewritten or a 
syntax preprocessor had to be written to change them. This put an additional 
burden on the user because in rewriting the source he had to substitute 
unfamiliar symbols for ones that he was used to. If a new syntax preprocessor 
had to be written he usually had to seek assistance from the program originator 
which resulted in additional costs and effort connected time delay. 

Additionally, if a user desired to link together separately assembled modules, 
he was required to use whatever, if any, linking support tools were available 
for the target machine or write his own. 

The above disadvantages provided serious obstacles to software standardization. 
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1.2 OBJECTIVES 

The primary objective of this effort was to standardize a NASA low cost 
Meta Assembler and Linkage Editor. The enhancements to the Meta Assembler 
defined for this contract include: the design and development of a 
User Oriented Syntax Definition capability and the design and development 
of a recognition capability to support these definitions in order to perform 
the assembly process. Also, the design and development of a generalized link- 
age editor and library creation and maintenance function was defined. 

The result of this effort resulted in the establishment of a Meta 
Assembler program and Linkage Editor program which operates in the environment 
of a large scale host computer and supports software development for flight 
and ground checkout computers (mini -computer class). 

Additionally, user and maintenance documentation was developed and the 
inherent capabilities of the program demonstrated. 

1 .3 TECHNICAL APPROACH 

The nract called for 7 major tasks to be performed. 

Task 1 - User Oriented Syntax Definition Capability 
Task 2 - Generalization of the Procedure Language 
Task 3 - Improvement to the Meta Assembler Error Diagnostics and 
Dynamic Debug Features 
Task 4 - Meta Assembler Documentation 
Task E - Development of a Generalized Linkage Editor 
Task 6 - NASA Goddard (GSEC) Delivery and Installation for the NSSC-1 
Task 7 - Meta Translator Installation and Training at MSEC 

Of these seven tasks, tasks 2 and 3 were deleted through renegotiation due 
to technical difficulty of task 1. Task 6 was deleted at the request of 
NASA and combined in part with task 7. 

^•3-1 Task 1 - User Oriented Syntax Definition Capability 

The existing Meta Assembler is designed to translate symbolic assembler level 

instructions into machine language instructions for a wide variety of target 
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computers. The adaptability is achieved via a set of target definition 
directives which parameterize the Meta Assembler for the subsequent assembly 
function. The target definition directives supply the architecture character- 
istics (e.g. , word size, register descriptions, character set definition) 
as well as the instruction set definition (mnemonic, operand description). 

Additionally, the Meta Assembler has built in directives to perform assembly 
time functions (e.g., data definition, parameter definition, location counter 
control, listing control, conditional assembly control, procedure definition 
and expansion). The syntax processing of the Meta Assembler directives is 
fixed (e.g., DATA, PROC, EQU, ORG) and at the instruction processing level 
flexibility is provided for operand definition rather than syntax definition. 
Therefore, the Meta Assembler represents equivalency in its assembly function 
with a correlating target machine and assembler syntax compatibility is not 
maintained. This can have the effect of requiring programmers to learn the 
equivalent assembler language and directive syntax instead of using the 
familiar target assembler syntax. Additionally, maintenance of a program 
cannot be performed by both the Meta Assembler and the target machine 
assembler due to the syntactical differences. 

This task alleviates the syntax incompatibility by providing the additional 
capability to allow the user to define the syntax of the assembler language 
and directives and the correlating semantics of the statements (e.g., generate 
intermediate language, perform an assembly time function). This was 
accomplished by designing a meta language for the purpose of defining 
assembler languages, their syntax and translation semantics. 

The processors developed for this capability are the meta language processor, 
the lexical processor and the generalized parser. The meta language processor 
is a pre-assembly function which processes the meta linguistic definition 
of the assembler language and generates a dictionary data set containing the 
syntax and semantic tables to be utilized by the generalized parser. 

This function need not be performed for each assembly. The generalized 
parser performs the first pass of the assembly utilizing the syntax and 
semantic tables produced by the meta language processor. The first pass 
accomplishes the source statements translation into the Meta Assembler 
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intermediate language which can then be processed by the existing second pass 
of the Meta Assembler to perform object module generation. 

The design intent of this capability was not to replace the existing Meta 
Assembler target definition and first pass process but rather augment the 
Meta Assembler with the optionally invoked generalized parser function as 

illustrated in Figure 1. Host portability of the enhanced Meta Assembler was 
preserved. 

Under this task a complete meta linguistic definition of the NSSG-I assembler 
language was developed. This represents part of the delivery items 
relative to Task 6. 

1 Task 4 - Meta Assembler Documentation 

A Detail Design Manual was produced which fully documents all subroutines 
and data areas of the Meta Assembler. This document is intended to support 
maintenance functions pertaining to the Meta Assembler. Included in the 

Detail Design Manual is an appendix devoted to host computer installation 
procedures . 

The existing Meta Assembler User's Manual was updated to include the 
enhancements and modifications performed during this effort. Meta Assembler 
error diagnostics are listed with appropriate explanations as an appendix 
to the User's Manual. 

Task 5 - Develop a Generalized Linkage Editor 
A generalized Linkage Editor function was defined, designed, developed, and 
validated with appropriate doGumentation supporting each phase. It provides 
the capability to utilize modular programming techniques in the application 
of the Meta Assembler by combining a user library of separately assembled 
object modules, produced by the Meta Assembler, into an absolute or relocatable 
load module on a large scale host computer. Its primary processing capability 
is to perform relocation and external linkage functions on the object modules 
processed. To implement a system generation capability the Linkage Editor 
additionally may access object modules from an object module library to satisfy 
undefined global references (see Figure 2). 


4 
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A critical aspect of the Linkage Editor will be its ability to respond to 
user defined parameters to fully utilize the resources of the target machine, 
specifically the NASA Standard Spacecraft Computer (NSSC-I), The resource 
parameters include the ability to optionally specify beginning addresses for 
some or all of the control sections represented in the object modules and 
to specify the order in which the control sections are to be loaded. 

The implementation of the Linkage Editor is in ASA FORTRAN IV, as is the 
Meta Assembler, to facilitate ease in transporting the function from one 
host computer to another. 

The absolute load module generation is in a standard format to maximize its 
applicability to a wide variety of target machines. This necessitates an 
output driver to be developed whenever a new target machine is interfaced. 
Under this task an output driver was developed to format the load module for 
loading and execution on the NSSC-I (see Figure 2). 


1-3.4 Task 7 - Meta Translator Installation and Training at MSEC 
For the exclusive purpose of maintaining the enhanced Meta Assembler ,the 
MDAG proprietary Meta Translator was installed at MSFC on an IBM 360. This 
installation included the delivery of source programs (tape), program listings, 
technical documentation and installation procedure description for the MDAC 
Meta Translator, the enhanced Meta Assembler and the generalized Linkage 
Editor (see Figure 3). 


Personnel training was conducted in the utilization of the Meta Translator. 


In addition, the NSSG-1 language definition and output driver were delivered 
to M5FG. The GSFC furnished test cases were also delivered (see Figure 4). 


1.4 RESULTS 

The Meta Assembler was enhanced to allow the user to define an assembler 
language syntax to be processed. This capability eliminated source language 
reformatting or ad hoc syntax recognizer development in order to maintain 
compatibility with a target machine assembler language syntax. 
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The original Metu Assembler was regenerated using the latest version of the 
MDAC Meta Translator. This regeneration provided an increase in efficiency, 
both execution time and memory requirements, and a more extensive dynamic 
debug capability. 

These improved dynamic debug features will provide support in the maintenance 
of the Meta Assembler itself. 

A generalized Linkage Editor was developed as a standard post processor for 
the Meta Assembler. The function of the Linkage Editor is to link separately 
assembled relocatable and/or absolute object modules into an absolute or 
relocatable load module. The Linkage Editor was written in FORTRAN IV to 
coincide with the host portability requirements of the Meta Assembler. 


The NSSC-I computer was the initial target computer. The Meta Assembler 
and Linkage Editor were configured to accept NSSC-I assembler language syntax 
and produce load modules that fully utilize the NSSC-I resources. 


The resultant Meta Assembler and Linkage Editor was installed at NASA Marshall 
Space Flight Center to facilitate centralized control of these NASA standard 
programs . 


To provide NASA MSFG the capability to maintain the Meta Assembler the MDAC 
propreitary Meta Translator program was installed at NASA MSFC and training 
was provided in its use. 


TO 
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2.3.1 MDAC-W Huntington Beach, California 

The McDonnell Douglas Automation Company provided support to the project through 
the use of its facilities - the GDC Cyber 74 and DEC PDP-10 computers. 

The MDAC-W proprietary Meta Translator was one of the primary support 
software products used in the performance of this project. 


2.3.2 NASA Marshall Space Flight Center, Alabama 

The host computer for the installation of the delivered software was the 
IBM 360 located in building 4708. 


13 


Section 3 

TECHNICAL PERFORMANCE 


3.1 META ASSEMBLER IMPLEMENTATION 

This section contains the implementation results for the Meta Assembler exten- 
sions. 


Task 1 - User Oriented Syntax Definition Capability 
The purpose of this task was to provide a user oriented capability to syntacti- 
cally define an assembler language, machine instructions and directives, 
enabling the Meta Assembler to maintain syntax compatibility with target com- 
puter assemblers. 


The objective of this task was to integrate a meta language definition of an 
assembler language into the Meta Assembler technique such that the built-in 
semantic and support processing is available to the user at the meta language 
level. The built-in semantic and support processing is represented by: 

° expression evaluation 
° assembler directive processing 
° intermediate language formatting 
° object generation 
° listing function 

The implementation approach was to develop a meta language to define the 
assembler language syntax and correlating built-in semantic functions. 

This meta language is input to a stand-alone preprocessor for translation 
into syntax and semantic tables which will guide the first pass processing 
by the Meta Assembler. A generalized parser was developed, integral to the 
Meta Assembler, to perform the alternative first pass of the cross assembly. 
The output of the generalized parser is an intermediate language (IL) data 
set such that the existing second pass of the Meta Assembler can complete 
the cross assembly by converting the IL into the object data file and 
generate a program listing (see Figure 6). 
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3. 1.1.1 Assembler Level Language Definition Meta Language (ALLOEF) 

The purpose of the meta language, ALLOEF, is to provide an easy to use 
environment in which to describe an assembler language syntax and correlating 
semantic process. The design of ALLDEF is based on the OPALDEF meta language 
developed by MDAC for the U.S. Army Armament Command, Frankford Arsenal. 

Key to the concept of ALLDEF is its correlation to a bottom-up operator 
precedence parsing function. This permits a simplistic meta language 
notation and results in efficient parsing. Basically, ALLDEF represents a 
"dictionary" definition concept where the symbols of the target assembler 
language are defined in terms of their spelling (lexically) and their meaning 
(semantics). The meanings are defined contextually, i.e., where the symbol 
may appear and translationally , i.e., what Meta Assembler built-in semantic 
function is to be performed. 

A statement in ALLDEF may take forms to define user types, parameter table 
entries, target machine characteristics , assembler language symbols, semantic 
functions and comments. The ALLDEF definitions are specified in a free-form 
structure with the constraint that user type, parameter table and target 
characteristic definitions must precede their references. 

User Type Definition 

A type is an attribute associated with a symbol which categorizes that symbol 
uniquely. Thus, a symbol may be bound unambiguously to an operator based on 
its type. A set of built-in types will be provided to the ALLDEF language 
includtng: 

a digit string 

a NUMBER symbol which has been converted 
to its binary representation, 
a character string which satisfies a 
definition of an assembler level 
mnemonic or symbol notation, 
a NAME symbol which is identified in 
the label field of a statement, 
a NAME symbol defined in the assembler 
symbol table as an address value. 


NUMBER 

VALUE 

NAME 

LABEL 

ADDRESS 
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CHAR_STRING 

SPECIAL 


SYMBOL 


a character string normally delimited 
and typed for text processing, 
a character string composed of special 
characters . 

a character string which cannot otherwise 
be typed as NUMBER, NAME, CHAR_STRING, or 
SPECIAL. 


The available built-in types are used to provide initial token classification 
and the set may be extended further via the TYPE statement in ALLDEF. This 
provides unique binding attributes for tokens defined in ALLDEF. 


Example: 


type 'REGISTER,* 'MEMORY, '... .$ 


Parameter Table Entry Definition 

A parameter table is available for utilization. Essentially, the entries 
in the parameter table are the translation time variables defined, optionally 
initialized, and used as desired. The parameter table is divided into two 
sections, a global and a local section. The global section contains the 
variable entries that are initialized only at the start of the assembly. 

The local section contains the variable entries that are initialized at the 
start of each statement assembly. Additionally, all of the built-in 

translation parameters are available in fixed entries in the parameter table 
including: 


CURSOR 


CURSOR CHAR 


OPCODE 


BIT LENGTH 


current input statement cursor position 

in the local section and initialized to 1. 

character under the CURSOR position, 

in the global section. 

operation code value for object generation, 

in the global section. 

bit string length for object generation, 

in the global section. 
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FIELDS 


LOCATION 


CTL-SECTION 


MEM-SIZE 

ADDRESSJNIT 

ACCESSJJNIT 

ERROR_SIZE 

VALUEJIZE 

OBJECT SIZE 


the number of fields to parse for a statement, 
in the local section and initialized to 3. 
assembly location counter, in the global section 
initialized to zero. 

current control section for LOCATION, in the 
global section initialized to 1. 


global section parameters correlating to the 
Meta Assembler SIZE directive 


The user may extend the parameter table via the GLOBAL and LOCAL statements 
in ALLDEF, 

Example: 

GLOBAL 'LEVEL'-!, 'NEST 

Global section definitions LEVEL is initialized 
to 1 and NEST is initialized to zero by default. 

LOCAL 'SOURCE', 'BEST*, 'STYPE' - DOUBLE... $ 

Local section definitions SOURCE and BEST 
are initialized to zero by default and STYPE 
is initialized to DOUBLE (previously defined 
on a TYPE statement). 


Target Machine Characteristics 

The target machine characteristics are the parameters lineded to perform the 
cross assembly function. Some of the characteristic parameters are 
maintained as fixed built-in entries in the parameter table (see paragraph 
2 . 1 . 1 . 2 ). 
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Assembler Language Symbols 

The process of building an assembler language “dictionary” consists of defining 

lotto T" ^ semantic 

unct.ons, t.e.. object generation and assembler directive processing. ALLDEF 

statements are needed to define the assembler level tokens in terms of 

rbTlfolT"'l™’“ 'Z''" and the semantic functions 

performed. It is at this point that the essence of unique assembler 

language translation into Meta Assembler intermediate language occurs. 

al°uLdTd!f‘ - AUDEF statements 

re used to define the assembler language symbols, i.e., instruction mnemonics. 

ec ive mnemonics, and the special operators of the assembler language 

statements, creating the environment for an operator precedence syntax 

processing. The remaining task is to define the syntactic meaning of the 

operator definitions. The syntactic meaning of an assembler level token 
defined m ALLDEF takes the form of: 


° definition of the results 

definition of the operands allowed 
definition of the operator precedence 
® parameter table action 
° semantic action 


The collective ALLDEF terms to define the assembler level symbols and their 
meaning comprise the ALLDEF statement. 

Assembler Level Operator Definition - The assembler level operator definitions 

describe the verbs and special operators of the assembler language and provide 

the mechanism to perform a statement parse. The operator definition term 

occurs first in an ALLDEF statement. Machine instructions and directives 

are the action verbs of the assembler statements which result in a statement 

evel semantic, i.e., object generation and directive function. Special 

operators are the sub-statement identifiers that perform on the action verb 

operands. Their associated semantics build toward full statement recognition 
at assembly time. 
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Examples : 

INSTRUCTION 'MOV: 
DIRECTIVE 'EQU': 
PREFIX OPERATOR'#': 
POSTFIX OPERATOR : 
INFIX OPERATOR',': • 


action verbs 


special operators 


Definition of Results - A result is the mandatory type of information to be 
returned to the parsing process upon complete recognition of an operator 
(other than the action verbs INSTRUCTION and DIRECTIVE). A result is expressed 
in terms of ALLDEF types. 

Example: 

RESULT=REGISTER 

Definition of the Operands Allowed - Operands are defined in terms of their 
order, optional ity, type, kind, and term or sublist structure. The order 
position of the operand is correlated to a left-to-right scan of the operands. 
The type must be an ALLDEF type. The kind refers to the built-in generic type 
used to further bind operands and operators, i.e., EXPRESSION. The sublist 
structure, SUBLIST, indicates a delimited term, i.e., a parenthesized notation. 
The keyword OPTIONAL defines the presence of an operand is allowed but not 
required. 


Exampl es : 

OPERAND(l) - REGISTER SUBLIST 

,0PIRAND(2) = OPTIONAL ADDRESS EXPRESSION 

Definition of the Operator Precedence - The precedence specified in a defini- 
tion provides the priority for reducing an operator to its result. Default 

precedence is assigned to the various operators, however, the precedence 
may be explicitly specified. 

Example: 

Pr: 'EDENCE=50 
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Semantic Action - The semantics of an operator definition are described in a 
semantic clause which explicitly specifies semantic functions or refers to a 
separate semantic definition statement. 

Semantic actions occur at two different levels of processing. First, there 
are the assembler function semantics which perform statement level semantics, 
i.e., symbol table definition and object code generation. Second, there are ’ 
syntactic processing semantics which manipulate parameter table variables and 
operands, i.e., building operand lists, in order to effect precise assembler language 
statement recognition. Additionally, decision making phrases and arithmetic 
operations are available to the semantic clause providing flexibility over the 
semantic definition. This consists of an IF-THEN-ELSE-END type of phrase 
structure and arithmetic function keywords. 

Action may be taken upon parameter table variables in the form of assignment 
statements. This is an itimediate translation semantic available for use 
at the language definer's discretion. 

Example: 

NLEVEL=NLEVEL+1 


The assembler function semantics are represented by directive processing, 

I.e., symbol table definitions, macro processing, literal pool processing and 
object generation. 


Examples • 

CREATE__S YMBOL ( OPERAND ( 2 } ) 

CREATE_DATA( 'DATA' ,0PERAND(1 ) ) 

LITERAL(0PERAND(3)) ) 

SECTION ('DATA') ' 

SECTI0N(0PERAND{1)) 

CREATE_MNEM0NIC(0PERAND{1 ) ) 
0BJECT(ADDRESS_TYPE(L0CATI0N_C0iJNTER),FlELD(0-3) = 
OPCODE, FIELD(4-7}=0PERAND(1 ,1) FIELD{8-15}= 
0PERAND(1,2)) 


symbol table processing 

literal pool processing 
control section processing 

mnemonic definition, ie. , macro 
I object code generation 
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The syntactic processing semantics perform actions upon the operands during 
the assembler level statement recognition process. 

Example; 

LISTF( 0 PEIMND( 1 ), 0 PERAN 0 * 2 ). 0 ' 65 ') build an operand list composed 

of 3 elements 

The decision making phrase provides the capability to have alternate paths 
as well as establish the truth condition for the operator definition 
recognition. Available to the IF phrase is the ability to test: 
operator kind, spelling or precedence 
® operand value 

operand presence (optional testing) 

° parameter table value 
value of expressions 


Exampl e : 

IF(PRESENT(0PERAND(1))) 

IF(SYMBOL_TYPE{ 0PERAND( 1 ) ) . EQ. REGISTER) , 
CHK-REGl , 

ELSE, 

CHK-REG2, 

EN0, 

LISTF{0PERAND(1 ) ,0PERAND(2)) , 

END $ 


_ALLDEF Operator Semanf'c Definition Example 

INSTRUGTION 'MOV: 0PERAND(l )=REG_RE6,RES[;iLT=D0UBLE, 

SEMANTIC=0PG0DE=0'01 ' ,BDL16$ 

INFIX OPERATOR RESULT=REG_REG 

OPERAND(l) = REGISTER, 

0PERAND{2) = REGISTER, 


SEMANTIG* 


SEMANTIG 'DBL16': 


GHK-REGS,LISTF, 
END $ 

BIT LENGTH=16 
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OBlEGT(ADDRESS_TYPE(LOGATIONj:OUNTER),FiaD{0-3)*OPCODE, 

FIELD(4-9)=0PERAND (!,]), 

FIELD(10-15)=0PERANDn ,2))$ 


An example of NSSC-1 assembly language is contained in Appendix B. 


3. 1.1. 2 


Assembler Level Language Lexical Meta Language (ALLLEX) 


Lexical Analysis 

The lexica) process), ,g is performed by interpet, 'ng a meta definition of the 
exicon to perform token identification in a top.down fashion. The meta 
angoage for defining the lexica! processing is very similar to the meta 
language of the MOAC Meta Translator and is processed by a preprocessor step 
subsequent to the ALLDEF processing of the syntax meta definition. 

The pri«ry purpose of the lexical meta definition is to define the assembly 
time token fetch and identification process. 


It became clear that a parameterized standard lexical function is prohibitive 
due to the context sensitive uniqueness found in assembler languages This 
has led to the necessity of providing a specialized meta language to adequatel 
address the token fetch and identification process. 


It is the responsibility of the lexical process to fetch a token and identify 
It as one of the basic types: 

a digit string token which can be 


NUMBER 


VALUE 

NAME 

LABEL 

CHAR STRING 


converted to a binary value, 
a NUMBER token which has already been 
converted to its binary representation, 
a character string token which has the 
properties of an assembler level mnemonic 
or symbolic notation, 
a NAME token which has been identified 
in the label field, 
delimited character string token 
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SPECIAL 


a token composed of special characters 
only as defined by meta language. 

SYMBOL - a token which cannot be otherwize 

identified as a NUMBER, NAME, CHAR_STRING 
or SPECIAL. 


The lexical meta definition provides a top-down, recursive descent, goal 
oriented technique for token fetch and identification. 


The meta definition consists of productions developed to guide the lexical 
process by defining the following lexical situations: 

° what is a NUMBER token 
° what is a NAME token 
° what is a LABEL token 
° what is a CMAR_STRINS token 
° what is a special character 
° what is a subfield separator 
° what is parse order for token identification 
° what is the end of a statement field condition 
® what is the end of statement condition 


The lexical meta language is a modified Backus Naur Format (BNF) notation 
which will provide the basic parse functions: 

° exclusive cursor control 
° truth/false path prediction 
° reoGcurance processing 
° recursive processing 
° literal string prediction 

The extended lexical parse functions include: 

° built-in primitive definitions 

e . g . LETTER .DIGIT , CHARACTER ,etc . 

° parse state conditional testing 

The ALLDEF PARAMETER table and built-in global variables will 
be available for assignment and conditional testing (e.g. , CURSOR, 
CURSOR CHAR, FIELDS, etc.) 
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token construction and assigning the initial identity (e.q 
NAME, etc.) ' ^ 


«hi,e there is a distinct separation of the lexical and syntactic parse 
functions, there is a common source of the overall • • 

state. Through the ALLDEF paraaieter table and other built-in global 
vartables. specialized parse functions can be controlled, i.e., label field 
nt,f,ca ,on. end of statelet detection, assembler processing ™odes 
special lexical and syntactic definitions (macro and text functions). 

Example: 

<T0KEN> ;= <NUMBER>//<NAME>//<SPEGIAL>//<SYMBOL>$ 

<NUMBER>:= (IF'O' ,BASE=8//BASE=10) , 

<DIGITSTRING>, 

(IF BASE EQ 8, TOKEN_VALUE=VALUE OF 

octai<digitstring>//token_value» 

VALUE OF <DIGITSTRING>),T0KEN_TYPE=^VALUE, 

IF NOT LETTER $ 

<DrGITSTRlNG>:= 1 to MANY DIGITS $ 

<nAME>;= LETTER, 0 to MANY (LETTER//DIGIT) , 

token_type=name$ 

<SPECIAL> :=( ■,■//'. 7/ 'f 7/ ■-■// '*7/ 7 ■ ) .TOKEN_TVPE-SPECIAL$ 

<SYMB0L>:. 1 TO MANY (IF NOT SPACE.NOT <SPECIAU, CBARACTER) .TOKEN TYPE 
=SYMB0L$ - 

3 .1.1. 3 ALLDEF Meta Language Processor 

A itieta language processor was developed to process syntactic meta definitions 
into the ALLDEF dictionary composed of the syntax and semantic tables. The 

The°AMnFr!”r ^ stand-alone preprocessor to the Meta Asserablei 

The ALLDEF dictionary file is preserved as an input file to the generalized 

parser function of the Meta Assembler which eliminates the need to execute 
the ALLDEF processor for each cross assembly. 

The design of the ALLDEF processor is based on the OPALDEF processor developed 

th OPS “f’®'' 

the OPALDEF metalanguage (see Figure 7). 
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ALLDEF ASSEMBLER 

PROCESSOR DICTIONARY 



Figure 7. ALLDEF Processor 
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3. 1.1. 4 ALLLEX Meta Language Processor 

A meta language processor was also developed to process lexical meta definitions 
into an existing ALLDEF dictionary. The ALLLEX processor functions as a 
post processor to the ALLDEF processor and a preprocessor to the Meta Assembler. 

The design of the ALLLEX processor is based on the MDAC Meta Translator. 

3.1 .1.5 Generalized Parser (ALTRAN) 

The ALTRAN processor will be developed as an integral module of the Meta 
Assembler. It provides the alternative first pass processing of the Meta Assembler 
by translating assembler language source statements into the Meta Assembler 
intermediate language structures and performing assembler directive semantics 
via the ALLDEF dictionary (see Figure 8). 

ALLTRAN Parsing 

The parsing technique employed in ALTRAN is a precedence analysis scheme 
utilizing a left-to-right .scan. A reduction of an operator and its operands 
to the defined result is made when another operator is recognized of a lower 
or equivalent precedence value. Any semantic associated with the reduced 
operator is also effected at that time. The assembler directive semantics, 
i.e., symbol table manipulation and control section activation, are performed 
immediately by built-in support routines. The object generation semantics 
build a list of intermediate language elements on the intermediate language file. 
During the parsing process of ALTRAN, the operators and operands are placed 
on stacks for evaluation. The binding of operands to operators is performed 
on the basis of the ALLDEF operator definitions. The proper operator 
definition is detected by matching the available operands with the ALLDEF 
operator definition which permits operator reduction to occur. The implication 
is that multiple definitions of the same operator are permitted. 

3.2 META TRANSLATOR IMPLEMENTATION 
3.2.1 Meta Translator Description 

The Meta Translator is a propreitary translator writing system (TWS) developed 
at MDAC-W that is a very effective tool for the generation of language 
translators (see Figure 9). It is machine independent in the class of medium 
'and large scale computers that have an ASA FORTRAN IV compiler. 
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Ftcjure 9. Meta Translator General Applrcation 
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Eve.y translator consists of a parser to recognite syntax, a procedure 
executor and a set of subroutines to perfo™ semantic functions, a number 
Of support routines that perform co»o„ functions, and a contro, driver to 
as an executive, controlling the flow of operations. 

The parser and procedure executor are generated by the Meta Translator 

ce they are language-dependent. The semantic procedures may invoice built- 

d user supplied subroutines. The support routines are not generate 

t are provided as an adjunct to the generated code. The contro, driver 

s short ma,n program which initiates translation, and is written by the 
language definer in FORTRAN IV. ^ e 

(seVFigur,r'"irL" definer 

and procedure executor by ^ e M^erTtlsuLV^ 

^ iranslator. A supporting BLOCK DATA 

~ - -- - — 

3-2.2 Meta Translator Application 

The Meta Translator was used to originally produce the Meta Assemibler syntax 

andTal' i-iPldmentation of the AUDtF 

nd ALLTRA# processors. This technique utilizes a meta language for defining 

tntax processing algorithms and greatly eases implementation and maintenance 


a't L™r'anVt??:"! 

at HSFC and the Meta Assembler meta language source was a deliverable item. 
3.3 SENERALIZFD LINKAGE EDITOR 
3.3.1 General Overview 

The Sensed Linkagl Editor (GLE) is a multi-functioned utilitv designed 
to aid the Meta Assembler user in the creation and maintenance of software 
systems built from Meta Assembler formatted object modules. 
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FORTRAN TRANSLATION EXAMPLE 


SDEeLARATiVENAME 


$DO DECLARATIVE - 


SDIMENSION 


.=SETCASEI- 
rDIMENSION', 'INTEGER'. 
'REAL', 'COMMON'. 'DATA', 
'EQUIVALENCE', 'DOUBLE*. 
'LOGICAL', 'COMPLEX'. 
'IMPLICIT'). 

.“CASE I OF 

ISDIIM E NSI ON.$l NTEG E R . 
SREAL.SCOMMON.SDATA, 
SEQUIVALENCE.SDOUBLE. 
S LO G I G A L ,$COM P L E X , 
SIMPLICIT). 

. =T EX T ($ D E e L AR ATI VEN A M E 
LIST OF 1000 
BEGIN 

SNAME, 

TEXT($NAME), . 
SFINDDIMENSION, 
SCOMMA 
END. 

TEXT(EJECT). 


/•DETERMINE DECLARATIVE TYPE 


/* PARSE THE DECLARATIVE 


). /• OUTPUT 'DIMENSION' 

/* PARSE THE ARRAY LIST 

/* PARSE AND OUTPUT ARRAY NAME 

/* PARSE AND OUTPUT PARENS AND 
/• SUBSCRIPTS. OUTPUT A COMMA. 

/* PRINT AND PUNCH OUTPUT IMAGE 


Figure 10. Meta Tra'nslator Example 



Functionally, the GLE provides three basic services: creation and maintenance 

of libraries of object modules, binding of separately assembled modules to 
form a generalized load module, and cataloging of object modules, libraries 
and load modules to gather descriptive information. 


3. 3. 1.1 Library Creation and Maintenance 

This service provided by the GLE gives the Meta Assembler user the capability 
to create a new user/system library directly from the output of the Meta 
Assembler. Once a library has been created, it may then be updated using 
Meta Assembler output and the old library to create a new library. 


3. 3. 1.2 Binding of Modules 

This is the primary service of the GLE. Its function is to bind separately 
assembled modules, developed for a common target machine and residing on 
user and/or system libraries, into a generalized load module. The generalized 
load module is then available for transformation into the structure required 
by the specific target computer loader. A wide range of control is given to 
the user, through the use of directives , for determining which modules and 
in what order will appear in the resultant load module. 


3, 3. 1.3 Cataloging of Standard Meta Assembler System Outputs 
This capability gives the user a tool to display descriptive information 
about each of the three Meta Assembler system outputs: object modules, 
library of object modules, and load modules. 


The available information includes: type of output, module name, module 

creation date and time, module version, target computer. 

3.3.2 Flow Through The Generalized Linkage Editor 

The flow of data through the GLE is controlled entirely by user supplied 
directives which represent; invocation of a basic service, tasks for a 
basic service to perform, and termination of a basic service. 

It is expected that a couple of basic flow paths will be performed again 
and again. With this in mind, the following descriptions will outline these 
two basic flows (a macro flowchart appears in Figure IV). 
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•IF TWQ LIBRARIES ARE MADE AVAILABLE TO THE LINKAGE EDITOR 
THEN THEY MUST NOT BE OF THE SAME TYPE. 


Figure 11. Row Through the Generalized Linkage Editor 
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3.3.2. 1 Creation of a System Library for General Use 

In a production atmosphere, there usually exists a set of object modules 
that perform widely needed utility functions: input/output, mathematical 

functions, date and time, etc. Once these functions are coded and tested 
they should be put into a library that is available to all users. The GLE's 
library creation and maintenance function will create a system library of 
object modules using the assembled utility functions as input. This 
library of utility functions is now in a form that may be used by the linkage 
editor service to satisfy references to them. 

When changes to the system library are necessary, the library service has 
capabilities to update the old system library against newly assembled modules, 
using directives, to create a new system library, 

3. 3. 2. 2 Creation of a User Library and Load Module Generation 

The Meta Assembler user will create a set of object modules to perform a 
particular task. As new tasks are required or old tasks become unnecessary, 
the set of object modules will change to reflect the current requirements. 

The GLE’s library creation and maintenance function (LCMF) can model such a 
sequence. Given an initial set of object modules, the LCMF can create a 
user library of object modules. As changes are made, the LCMF can make the 
required changes to the user library. 

Once a library is built, the linkage editor service may then be invoked. 

The linkage editor service, using a user library and/or system library, 
will create a load module. 
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3.3.3 Use of the Generalized Linkage Editor 

Each service of the GLE is accessed by user directives. These directives 
control service invocation, service termination and service tasks to 
be performed. 


A11 directives are of the general format described below. 
3. 3. 3,1 Directive Coding Conventions 


Notation Used to Describe Directives 

The descriptive notation used to define the syntax of the input directives 
makes use of upper and lower case letters and the characters left bracket ([) 
right bracket (]), periods( . ..) , and vertical bar (|). 

All keywords and other explicitly required symbols appear as upper-ease or 
special characters. An implicit operand appears as a lower-case name which 
is described in a narrative subsequent to its usage. 

An optional operand is shown enclosed within brackets ([]) . Occasionally, 
more than one level of optional ity is required and is described in terms 
of brackets within brackets: 


MAP 


ON 

OFF 


; describes MAP; or 

MAP ON; or 
MAP OFF: 


Choosing one of a list of operands is denoted by listing the operands 
vertically and enclosing them with vertical bars {||): 
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; describes ENTRY module; or 
ENTRY (symbol); or 
ENTRY (addr); 

Specifying a repetitive collsction of identical operands is described by 
following the operand with a triple dot {...); 

name [,name...] describes name or 

name, name or 
name, . . , ,name 

Format of Directives 

All GLE directives are formed according to the following rules and 
restrictions: 

All directives are free-form using columns 1-72 
Blanks are ignored and are used for readability only 
Each directive is terminated by a semicolon 

All text between the strings /* and */ is ignored, this string may 
not contain intervening blanks. 

More than one directive may appear on a card 
Directives may be contained on more than one card 

The following example illustrates the preceding points: 

‘ 72 73 80 


LIBRARY 

DIR 

001 

LIBRARY SERVICE FUNCTION */; 

DIR 

002 

BEFORE A,B; /*PUT B BEFORE A, AND */A 

DIR 

003 

FTER C/*PUT/,D; END; 

DIR 

004 

LIN^KEDIT; INCLUDE A:SLIB(4000) 

DIR 

005 

, SI ( 1 ) ,S2 (2 ) ;MAP0N ; END ; CATALOG 

;IR 

006 

;FILES=8,ULIB /*,*/, SLIB; 

/DIR 

007 

*GATALGG END*/ END; 

DIR 

008 


ENTRY 


rnodul e 
symbol 
addr 


) 
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3.3. 3.2 List of Generalized Linkage Editor Directives 

The directives listed below give a quick summary of capabn ’ties for each 
basic service provided by the GLE. 


Ubrary Creation and Maintenance Function Directives I 

LIBRARY Invoke Library Function 

„ Library from Meta Assembler Output On / 

Specify name of library 

° Specify kind of library I 

Position for a new module ‘ ‘ 

Position for a new module 

Delete modules from old library ■ ^ 

Ignore new module 


° RENAME 
° NO AUTOREP 


Give module rew name 

Only processes new modules named on before, 


° REPLACE 
° END 


after and replace directives 
Allows select replacement of modules 
Terminate library function 


Linkage Editor Bi recti ves 
° LINKEDIT 
° FILES 
° RELOCATION 
” MODE 
“ INCLUDE 
° EXCLUDE 
° NOULIB 
° NOS LIB 
RENAME 
° ENTRY 

° name 
° MAP 
° GSEGT 

° BOUND 
° END 


Invoke LINKAGE EDITOR 

Indicates file to be linked 

Specify address fields 

Force type of load module 

Force inclusion of a module from a library 

Force exclusion of a module from load module 

Force exclusion of entire user library 

Force exclusion of entire system library 

Cause external reference name change 

Specify execution start address 

Name load module 

Turn link map listing on or off 

Cause assembly time control sections to 

be loaded consecutively 

Determine module bounding 

Terminate linkage editor function 
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Invoke catalog service 
Specify which files are to be cataloged 
Terminate catalog function 

3.3.3 3 Use of the Library Creation and Maintenance Function 
An important function of the GLE is to be able to create and maintain two 
types of libraries; system and user. The purpose of a library in the GLE 
system is to provide the user with a utility with which to manipulate 
assembled ob.iect modules and to provide the linkage editor with a set of 
object modules from which external references may be satisfied. 

Even though there are two distinct types of libraries, the only real 
difference between them is in the way they are used by the linkage editor. 

Structurally, a system and user library are equivalent. 

Modes of Use 

The library creation and maintenance function (LCMF) operates in two modes; 
creation and maintenance. 

Creation Mode - The creation mode of the LCMF causes the object modules output 
from the meta assembler to be fonnatted into a standard library (see Figure 12). 

During library creation, the following restrictions must be kept in mind: 

° A library may not contain modules with duplicate names 
° The CREATE directive is mandatory and must be the second directive 
° NAME, KIND and PASSWORD are the only other directives allowed 
° The library will contain the modules in the order in which they 
are encountered. 

Maintenance Mode - If the CREATE directive is not the second directive ! 

encountered then the mode is assumed to be the maintenance mode. Processing i 

of new modules is handled by two basic procedures: implied automatic j 

replacement, and directed replacement by use of directives. I 

I 

If no processing directives are given, then the LCMF creates a new library I 

I 

by replacing the modules of the old library with modules that have the same \ 
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TYPE OF FJLE • L18RAHY 


NAME OF LIBRARY 


KINO OF LIBRARY - USER/SYSTEM 


CREATION DATE 


CREATION TIME 


NUMBER OF MODULES IN LIBRARY 


MODULE NAME OF FIRST MODULE 


PTH TO 

MODULE INFOR 


MODULE NAME OF LAST MODULE 


PTRTO 
MODULE INFO 


FIRST MODULE INFORMATION (DSC, DICTIONARIES, PTR TO OBJECT TEXT) "W 


LAST MODULE INFORMATION (DSC, DiCTIONARJES, PTH TO OBJECT TEXT) 


TEXT 

OF 

OBJECT 
MODULES 
IWITHOUT 
OSe AND 
DICTIONARIES) 


Figure 12. Standard Library Format 


40 




name as output from the Meta Assembler. Any new modules will be written 
at the end of the new library. 


If processing directives are given then transcription of modules to the new 
library will take place according to the directives. 


A functional flowchart of the LCMF appears in Figure 13, 

Detailed Description of lCMF Directives 

FORMAT 

LIBRARY; 

DESCRIPTION 

This directive must be present as the first directive to invoke the LCMF. 

FORMAT 

CREATE; 

DESCRIPTION 

This directive must be the second directive encountered in order to 
cause a new library to be created, using Meta Assembler output only. 

If CREATE is not the second directive encountered then it is assumed 
that an old user or system library is available to update against. 

FORMAT 

NAME=1 ibname ; 

DESCRIPTION 

This directive uses the symbol string "1 ibname" to give the library a 
name. If this directive is absent for a creation mode then a default 
name of "LIBRARYl" is given to the library. 

An updated library retains its original name unless changed by the NAME 
directive. 


FORMAT 


KIND = 


USER 

SYSTEM 



Figure 13. FunctionaJ Flowchart For the Ubrary Creation 


and Maintenance Function 
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DESCRIPTION 


This directive provides the library with a kind attribute. If this 
directive is absent for a creation mode then a default kind of "USER" 
is given to the library. An updated library will retain its original 
kind unless changed by the KIND directive. 

FORMAT 

NOAUTOREP; 

DESCRIPTION 

This directive declarer, that the LCMF function will not replace all 
modules from the old library with modules from the Meta Assembler having 
identical names, but selectively replaced modules according to REPLACE, 
BEFORE and AFTER directives. 


FORMAT 

BEFORE oldmod, new mod.j [, new mod.....]; 

DESCRIPTION 

This directive causes the LCMF to insert the "newmod" modules from the 
Meta Assembler before the specified "old mod" for transcription to the 
new library. This causes automatic deletion of old modules having the 
same names from the old library. 

FORMAT 

AFTER oldmod , newmod.j [, newmod. . . . ] ; 

DESCRIPTION 

This directive causes the LCMF to insert the "newmod" modules from 
the Meta Assembler after the specified "oldmod" on the old library for 
transcription to the new library. Insertion of this type causes 
automatic deletion of old modules having the same names from the old 
1 i brary . 


FORMAT 

PASSWORD^ pas sword ; 

DESCRIPTION 

This direci.ive specifies a password for the library. If this directive 
is absent then there is no default password given to the library. An 
updated library will retain its original password unless changed by the 
PASSWORD directive. 
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FORMAT 


J 


DELETE o1dmod2 [,oldmod ]; 

DESCRIPTION 

This directive causes the LCMF to not copy the "oldmod" modules from the 
old library to the new library. 

FORMAT 

IGNORE new mod^ [ , newmod^. . . . ] ; 

DESCRIPTION 

This directive causes the LCMF to ignore the “newmod" modules from the 
meta assembler during processing. 

FORMAT 

RENAME oldname^ = newname^ [,oldname.= newname ]; 

DESCRIPTION ^ 

This directive assigns a new name to a module that will appear in the 

new library. If any other directives refer to this module, the old name 
should still be used. 

FORMAT 

REPLACE newmod^ [ ,newmod^. . . . ] ; 

DESCRIPTION 

This directive is meaningful only during the effect of a NOAUTOREP directive. 
It causes the "newmod" modules to replace modules on the old library 
with the same names on the new library. 

FORMAT 

END; 

DESCRIPTION 

This directive causes termination of directive reading for the LCMF 
and initiates processing of the directives. 

Examples of LCMF Use 

For the following examples assume the existanee of two Meta Assembl er generated 
files, A and B, of object modules containing modules MA, MB, MC, MD and 
modules MD, MA, OX, OY, OZ respectively. 
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Example 1. Creation of a system library LIBl from file of modules B. 
Direetives; LIBRARY; 

CREATE; 

NAME=LIB1; KIND=SYSTEM; 

END; 

System Library LIBl contains MD, MA, OX, 0Y,0Z. 

Example 2. Automatic update of LIBl using file A to create user 
1 ibrary LIB2. 

Directives: LIBRARY; KIND=USER, NAME=LIB2; END; 

User Library LIB2 contains: 

MD from A 
MA from A 
OX from LIBl 
QY from LIBl 
OZ from LIBl 
MB from A 
MC from A 

Example 3. Restore MA from B on LIB2. 

Directives: LIBRARY; LIBRARY; 

NOAUTOREP; IGNORE MD;0X,0Y,0Z; 

REPLACE MA; or END; 

END; 

User Library L1B2 contains: 

MD from lIB 2 
MA from B 
OX from LIB2 
OY from LIB2 
OZ from LIB2 
MB from LIB2 
MC from LIB 2 
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3. 3. 3. 4 Use of LINKAGE EDITOR Function 

The most important service provided by the GLE is the LINKAGE EDITOR (LE). 

The LE service provides the i'ieta Assembler user with the means to generate 
a standard format load module (see Figure 14 ) by binding separately assembled 
modules that reside in user and/or system libraries. 


Since the LE must handle a variety of linkage editing requirements, a set 
of directives has been provided to give the user direct control over much of 
the Toad module generation process. The basic control features are: 

® specification of execution start address 
° order of module appearance in Toad module 
® 1 ink map generation 


Data Flow through the LINKAGE EDITOR 

The LE expects as its primary inputs a user library of object modules from 
which to form a basis for a load module, and an optional system library 
from which to satisfy external references. The LE then reads and decodes 
the user directives, if any. 

A "task" table is initialized with the decoded directives. Pertinent 
information includes: module order and start addresses supplied by "INCLUDE" 
directives, library to find module, and modules to exclude from the load 
module. If no service directives have been input then the "task" table is 
initialized by using the entire user library. 

The "task" table is then processed to determine all the modules that will appear 
in the load module. This processing includes searching for definitions to 
any undefined references. 


Once all the modules to be linked have been determined, addresses for all modules 
and control sections can be assigned. This completes filling in the "task" 
table. If a link map has been requested then the "task" table is used to 
create the map. 


All that remains to be done is to generate the standard load module. First, 
the header block is written. The user and/or the system libraries are then 



PILE TYPE - LOAD MODULE 


LOAD MODULE NAME 


ERRORS - Y/N 


CREATION DATE 


LOAD MODULE KINO - REL/ABS 
TARGET COMPUTER 


CREATION TIME 


LOAD MODULE LENGTH 


EXEeUTIGN START ADDRESS 


END OF MODULE - Y/N 


LENGTH OF RECORD 


LOCATION COUNTER FOR FOLLOWING CODE 


RELOCATION BITMAP = V/N 


RELOCATION BIT MAP 


LENGTl! OF MAP 


TEXT BIT STRINGS 


HEADER 


BITMAP 


> BIT STRINGS 


Figure 14. Standard Load Module Format 


t CODE BLOCK 

FOR CONSECUTIVE 

ADDRESS 

LOCATIONS 
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read sequentially. As a new module is read, it is either skipped or processed. 

task table. When the libraries have both been processed the linkage edition 
complete. Figure 15 contains a functional flowchart of the LINKAGE EDITOR 
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Control of Load Module Generation 

The GLE gives the user a wide range of control over the load module creation 
process. This control is divided into four main sections; load module 
type, execution start address, modules that will appear in load module, 
and generation of a link map. 

General Directives 

These directives control ob/ious features in the LINKAGE EDITOR. 

“ ClNKEDITi 

Format 

LINKEDIT; 

Description 

This directive is required to invoke the LINKAGE EDITOR service. 


Format 

NAME=lmod; 

Description 

The user may supply a name to oe given to the generated load 
module. If the optional NAME directive is included, then the 
name of the load module will be 'Imod'. In the case where the 
directive is not included, then the default name of 'LOAD 
MODULE T will be supplied. 

Format 

END; 

Description 

This directive terminates service directive reading and causes 
the LINKAGE EDITOR to perform the requested services. 
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Load Module Generation Node 

The GLE will nave the ability to produce load modules for a wide variety of 
target computers. The intent of the load module generation mode is to 
interface with various target machine loaders by producing absolute or 
relocatable load modules as required. 


i RELQCATIOn 


Format 

RELOCATION=(startbit: endbit) [ , (startbit: endbit) , . . .] ; 

Description 

This directive provides the GLE with a specification of all 
the fields that may contain addresses during an assembly. 
This allows the load module to create a relocation bit 
map, based on the specified fields, so that a relocating 
loader will know which addresses will need a load bias 
added. The ‘startbit* indicates the starting bit position 
and the 'endbit' indicates the ending bit position for a 
field. All fields are described left to right with 
fait 0 (zero) assumed to be on the extreme left. 



0 


n 


The relocation bit map will be created only if the load 
module mode is 'REL' (see the MODE directive). This 
directive is mandatory and must oe the third linkage 
editor directive. 


mm 


Fo.rmat 


MODE 


,ABS 


|REL I 

DescriDtion 

In the absence of the MODI directive, 
module will be relocatable unless: 


® the ENTRY directive is given 
® no relocatable text is found 
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the mode of the load 



^ecutio n Start Address Specification 

The starting address for execution of the load module produced by the GLE 
can be specified by the optional ENTRY directive. 

" 1Toy] 

Format 


module 


/ 1 symbol 

\ 

\ I addr 

1 

/ 


Description 

A start address may be specified by giving the name of an 
object module. If the module has an end transfer address 
specified, then this address will be used, othenvise the 

default end transfer address as supplied by the Meta Assembler 
will be used. 

If a ^symbol' is used to specify the start address, then the 

definition of this symbol, as supplied by the LINKAGE EDITOR, 
.will be used. 

The use of 'addr' gives the user the ability to specify an 
absolute address for the start execution. It must be 
described i„ the seme base as the ceta assembler output Hstie,. 

Module Appearance in a Load Module 

The essence of module binding is the determination of the modules that will 
appear ,n the load module, the order in which they will appear in the load 
module, and the types of addresses that may be bound. 

At this time, the LINKAGE EBITOR will be able to handle three addressino 
schemes provided by the Meta Assembler; direct memory addressing, base ' 
displaced addressing, and location counter relative addressing. 
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There are several user directives available to determine which object modules 
will appear in a load module; ULIB, SLIB, EXCLUDE, RENAME and INCLUDE. 

Even with the user directives, there are important assumptions that will be 
made when processing object modules using these directives. 

The first assumption concerns the default processing of external references. 
If a module is needed for satisfaction of an external reference, then it 
will be searched for. The first olace to look will be the 'task' table to 
see if it is already linked. If it is not linked, then the user library 
will be searched. If the user library does not contain the module, then 
the system library will be searched. If after searching the system library 
the module is still not found, then the reference will remain unsatisfied. 

So we see the search hierarchy is: 

1) already linked 

2) user library 

3) system library 

The search hierarchy may be changed by use of the FILES, N0ULIB,N0SLIB and 
EXCLUDE directives. 


O 



Format 

FILES ![USER]1[,1SYSTEM]! ; 

Description 

This directive indicates the files to be used in order to create 
the load module. This directive is mandatory and must be the 
second directive encountered. 
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o 


tlNCmPEl 


Fonnat 


INCLUDE module [(msa)][,csect(csa}...][: 
Description 


ULIB 

SLIB 


]; 


This directive causes the forced inclusion of 'module' from 
an optional library. The directive also allows a starting 
address, 'msa ' , to be specified for the module. Additionally, 
assembly time control sections, 'csect', may have starting 
addresses specified. This directive has the power to determine 
not only order of appearance but starting addresses as well. 


There are some restrictions depending upon the memory allocation 
scheme of the Meta Assembler. If the mode of the load module 
IS defined as the ••section "mode and 'msa' is specified, there 
will be a warning. However, the control section address will 
&e allocated back-to-back for the specified module. If the mode 
is "normal", -'-rasa' can be specified but any control section 
address, 'csa', will be ignored if specified. 


If this directive is not included in the creation of the load 
module, then ALL the modules from the user library will be 
included as a default. 

All addresses must be specified in the base of the Meta Assembler 
output listing. 


" {IXCLUDEI 


Format 

EXCLUDE modnam[,modnarn. 
Description 


ULIB 

SLIB 


This directive forces the exclusion of partiGular modules from 
appearance in the final load module. If no library is specified, 
then the module is ignored no matter which library it is found on. 

This affects the search hierarchy by implying which library may 
contain the module. 
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“ iNOULIBj 


Format 

NOULIB; 

DescriPtign 

This directive forces exclusion of all modules in the user 
library from appearin§ in the final load module. This implies 
that the search hierarchy effectively becomes: 

1) already linked 

2) system library 

“ INQSLIB 

Format 

NQSLIB; 

DescriDtion 

This directive forces exclusion of all modules in the system 
library from appearing in the final load module. Therefore, 
the search hierarchy effectively becomes; 

1 ) already 1 inked 

2) user library 

® I^NAME 


Format 

RENAME oldname=newname [,oldname=newname,...]; 

Description 

This directive causes external references to 'oldname' to be 
satisfied by the definition supplied by 'newname*^ If 'newname 
is one of the external references to a module, that has been 
mentioned on an EXCLUDE di»"ective, then 'oldname* will not be 
renamed and will be left as undefined. 
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o 


iGSECtl 


Format 

GSECT esect.csa [, bound]; 

PesGrlptlon 

The GSECT directive causes text in control section 'csecf 
from all linked modules to be linked consecutively into one 
global control section, starting at address 'csa'; Optionally 
included is the bounding Information, 'bound', to be used to 
determine where to start .addresses in this section when 
the next module is eneountered. 

If the memory allocation scheme is defined as the normal mode, 

then this GSECT directive will cause the error of memory over- 
lapping. 


0 


The address must be deseribed in the base of 
output listing. 


the Meta Assembler 



Format 

BOUND start [.next]; 

Description 

The optional bound directive controls location counter processtn 
for modules that are not supplied with starting addresses. The 
^efault values would cause modules to start at location 0 and 
be butted up against one another. 


The address must be deseribed i 
output listing. 


n the base of the Mdta Assembler 
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Generation of a Lin k Map 

The useThas contl^l over the Inclusion or exclusion of a 

of the UNME EDITOR outputs. This control is available 
optional MAP directive. 


link map as part 
through the 




ON 

OFF 

GLOBAL ’ 
_M0DULE_, 


Description 

If the MAP directive is included without an operand or is not 
included, then the default information will be generated with 
the unsatisfied external map. When a link map is generated, tho 
fonowing fixed contents will be available. All addresses will be 
pnntec in the same base as the Meta Assembler output listinq 
° Default map 


Echo of input directives 
Error/warning messaoes 
load module header information 
“ Creation date and time 
° Load module kind 


Load module length 
Execution start address 
Block assignment' 

Name of module and control section 
° Start addiress 
“ Length 


Library linked from 
“ Relocation fields 
° Module map 


External references 
External definitions 
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° Global eross-referenee map 
“ Name of definition 
“ Defined value 
® Module name defined 
° References to definition by module 
° Unsatisfied externa'l 
® External references 
“ Module name referenced 
® References to externals 

Example of Link Edit Use 

The directives described previously imply a hierarchy of ordering on 
object modules and control sections. The simplest explanation of this 
hierarchy is through the use of an example. 

Example 1. Show ordering hierarchy. 

Assume the memory allocation scheme is the section mode and the 
base is octal. 

Let object modules PGl , PG2, PG3 and PG4 exist. 

PGl contains A1 , A3, B1 and B2 as control sections. 

PG2 contains Al, A5, 80 and 82 as control sections. 

PG3 contains AO, A2, A7 and 81 as control sections. 

PG4 contains A8 as a control section. 

PG2 and PG4 are needed to satisfy external references. 

Given the following directives, show the starting addresses. 

LINKEDIT; 

FILES USER; 

REL0CATI0N=(0;n), (12:23); 

NAME=LM0D; 

MODE ABS; 

80UND 5000; 

GLOBAL Al ,100,2; 

GLOBAL 81,1000; 

INCLUDE PGl; 

INCLUDE PG3( 200), A7(7000); 

END; 
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8000 


7 00 

200 

1000 

5000 

A1{PG1) 

A0(PG3) 

Bl(PGl) 

A2(PG1) 

A7(PG2) 

A2(PG3) 

B1(PG3) 

B2(PG1) 




A5(PG2) 




B0(PG2) 




B2(PG2) 




A8(PG4) 


A7(PG3) 


I 
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3. 3. 3. 5 Use of the Catalog Function 

During use of the Meta Assembler system, many files will be created along the 
path to load module generation. Some of these files, such as libraries, 
will be saved and used many times. To aid the user with configuration control, 
a catalog function is provided by the GLE. This function extracts descriptive 
information about the three basic Meta Assembler system outputs object 
modules, libraries of object modules, and load modules. 


Summary of Catalog Directives 
° CATALOG 

° files 

° END 


Invoke catalog service 

Specify which files are to be cataloged 

Terminate catalog function 


Retailed Description of Catalog Directives 
° ICATALOGI 


Format 

CATALOG; 

Description 

Mandatory directive required to invoke the CATALOG function. 



Format 


Description 


filename 

un 


f i 1 ename 

[/F],... 

logical unit) 


> 

logical unit 





During a GLE run, several files are created. Before the LIBRARY 
function, a file of object modules generated by the Meta Assembler, 
known as OBJ, and optionally an old 1 ibrary of object modules to 
update, known as OLIB, exist. After the LIBRARY function, a new 
library, known as NLIB, exists. Before the LINKAGE EDITOR function, 
a user and/or system library, known as ULIB and SLIB, respectively, 
exist. After the LINKAGE EDITOR function, a load module, known 
as LMOD, exists. 
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So, at any of the described points, several files with generic 
names are available for cataloging. In addition to their 
generic names, the files will also have a FORTRAN logical unit 
associated with them. The table below describes the 'filename' 
and its corresponding 'logical unit'* 


The '/F' indicates the full catalog for the file mentioned. 


FILENAME 

OBJ 

OLIB 


NLIB 

ULIB 


SLIB 

LMOD 


9 


po 


LOGICAL UNIT 
8 
7 
9 
9 
11 
12 


Format 

END; 

Bescri pti on 

This directive causes the CATALOG function to perform the 
catalog of files. 

Available Information 

The information that is available for each of the three basic files is 
shown below. 


Object Module 

° Object Module Description (DSC) 

® Control Section Sictionary (CSD) 

“ External Reference Directionary (ERO) 
° External Definition Dictionary (EDD) 

° Vector Symbol Dictionary (VSD) 

° Object Text (TXT) 

° Object Module End (END) 

° Object Module EOF (EOF) 


'/F' 

only 

'/F' 

only 

>/F’ 

only 

'/F' 

only 

•/F' 

only 

./p, 

only 
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Library of Object Modules 
° Library Header 
“ Module Name List 
* Object Module Description (OSG) 

® Control Section Dictionary (CSD) 

® External Reference Dictionary (ERD) 
® Vector Symbol Dictionary (VSD) 

® End Marker 
“ Object Text (TXT) 

° Object Module End (END) 

° Object Module EOF (EOF) 


7F' only 

'/F' only 
'/F' only 
7F' only 
7F' only 
7F' only 
7F' only 


Load Module 

“ Load Module Header 
“ Relocation Address Fields 

® Text Sit Strings with Relocation Bit Map : 7F' only 

® End of Load Module 


Examples of Catalog Use 

Example 1, Catalog all files after Toad module generation 
Directives: LIBRARY; 

CREATE; 

NAME=EXLIB;KIND=USER; 

END; 

LINKEDIT; 

FILES USER; 

REL0CATI0N=( 0 : 11 ) , ( 1 2: 23) ; 

ENTRY MAIN; 

INCLUDE MAIN (0): ULIB; 

END; 

CATALOG; 

FILES=0BJ/F,NLIB,9/F, LMOD ; 

END; 

Note: File OLIB is not cataloged because the library function operated in 

a creation not a maintenance mode. 
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Example 2. 
its type. 
Directives; 


Catalog of an unknown file on FORTRAN logical unit 8 to detemine 


CATALOG; 

FILES=8; 

END; 


3.4 INSTALLATION AND TRAINING 

This section describes the delivery, installation and training procedures for 
the products developed under this contract. The facility utilized for 
installation and training was MSFC '’t NASA request. 

3.4.1 Task 7 - NASA MSFC Delivery 

The enhanced Meta Assembler, developed under Task 1, and the Linkage Editor, 
developed under Task 5 was installed at NASA MSFC on an IBM 36Q {see Figure 3). 
To provide system maintenance capability at MSFC the MDAC proprietary Meta 
Translator was alos be installed on the IBM 360. The delivery consisted of 
the following: 

° Installation on the MSFC IBM 360 
° MSFC Installation Verification 

“ Meta Assembler System/Meta Translator Demonstration 
° Personnel Training at MSFC 
° MSFC Deliverable Items 

3.4.2 Installation on the MSFC IBM 360 

THe MSFC IBM 360 was selected as the host machine for the installation of 
the enhanced Meta Assembler, Linkage Editor, NSSC-1 target output driver, and 
MDAC Meta Translator. The procedures to perform the installation of the 
enhanced Meta Assembler, Linkage Editor, NSSC-1 target output driver, 
and MDAC Meta Translator were: 

° to develop IBM 360 JCL for file creation, Meta Translation, 

FORTRAN compilation, link edit and execution of the components 
of the Meta Assembler system. 

° to determine the overlay structure for the Meta Assembler 
° to meta translate the Meta Assembler component meta language 
descriptions 

° to compile the Meta Assembler FORTRAN source 
° to link edit the Meta Assembler system object modules 
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3.4.3 ^ SFC Installation Verificaticn 

The installation verification was performed utilizing standard test cases 
or the Meta Assembler system and the meta language definition of the Meta 
Assembler for the Meta Translator. The verification procedure exercised 
each Meta Assembler system program involving the NSSC-1 assembler creation 

The Meta Translator was verified by regenerating the Meta Assembler parsing 
subroutines via meta language processing. 


Ifeta Assembl er System/Meta Translator Oemonstration 
The Meta Assembler system and the Meta Translator demonstration consisted 
of reproducing the verification process utilizing the standard test cases 
and the Meta Assembler meta language definition. 

3.4.5 Demonstration for the NSSC-I 

The system was demonstrated as fully supporting assembly level software 
development for the NSSC-I. This was performed via cross assembly of GS^C 
supplied NSSC-I programs, object module link edit, and load module formatting. 

The NSSC-I assembler language definition in ALLDEF and ALLLEX and processing 
by both the ALLDEF and ALLLEX processors was also demonstrated. Since a NSSC-I 
computer was not available at MSEC, actual execution could not be perfonned. 

3-4.6 Personnel Training at MSFC 

A period of one week was allocated for personnel training at MSFC. The 
primary thrust of this training period was toward Meta Assembler system 
maintenance. Items addressed were; 

ALLDEF processor design and use 
ALLLEX processor design and use 
Meta Assembler design and use 
Linkage Editor design and use 
Meta Translator Utilization 

3.4.7 MSFC Deliverable Items 

All installation support materials were included in the delivery as follows: 
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® Meta Assembler system FORTRAN source on magnetic tape 
® Meta Assembler system program listings 
° Meta Assembler meta language source on magnetic tape 
° Meta Translator FORTRAN source on magnetic tape 
° Meta Translator User's Manual 
° Installation procedure documentation 

Available Meta Assembler system user oriented documentation was delivered at 
this time. This delivery task, however, preceded the formal doGumentation 
development. All formal documentation. Task 4, and final product versions 
will be made available to MSFC for subsequent installation. 

3.4.8 6SFC Deliverable Items 

Due to the cancellation of the GSFG installation at NASA request, items which 
were scheduled for this delivery were delivered to MSFC. These items, all on 
magnetic tape were: 

® NSSC-1 ALLDEF source 
° NSSC-1 ALLLEX source 
° NSSC-1 target output driver source 
° GSFC furnished test cases 

3.5 META ASSEMBLER DOCUMENTATION 

This section pertains to the Meta Assembler system documentation developed 
under Task 4. The two types of documentation produced are: 

° User Manual s 
° Detail Design Manuals 


3.5.1 User Manuals 

Comprehensive user manuals were developed for each of the Meta Assembler 
system programs including: 

° ALLDEF User Manual 
° ALLLEX User Manual 
° Meta Assembler User Manual 
® Linkage Editor User Manual 


66 



The content of the user manuals is presented in a topical narrative fashion 
and thoroughly discusses the user interface considerations including: 

° product overview/ capabilities 

detailed presentation of user interface 
(control cards, language statements, etc.) 

® extensive examples of user interface 
° assumptions and restrictions 
" diagnostics 

3.5.2 Detail Design Manuals 

To support the maintenance aspect of the Meta Assembler system, detailed design 
documeitation was developed for the following programs: 

° ALLDEF processor 
° ALLLEX processor 
° Meta Assembler 
° Linkage Editor 
° NSSC-I target output driver 

The content of the detail design manuals is presented with a blend of topical 
narrative discussions and supporting schematic representations including: 

° program capabilities 
° functional flow chart 
° block structure diagram 
° input/output description 
global data area description 
° subroutine summary 

function description 
local data description 
system interface requirements 
° host installation procedures 

machine dependent considerations 


67 



APPENDIX A 
SCWEDULE/MILESTONES 


GRiGsfi^r, Page fs 

OF POOR QUALITY 



TO MSFC 


I a 

6f I V 


Project Schedule 




Appendix B 

ALLDEF NSSG-I DEFINITION 
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assembly language OEFIMJTION (ALLDEF) 


17-APR-79 


16143 PAGE 


CO 


( '■ 

O 

c 

o 

c 


•n 


c 

o 

o 

r 

V 

o 

o 

C'^ 

o 


/• definition qf nssg -1 Assembler »/ 

/• MAGMINe OESgRiPtIoN A'Nd enviornment */ 

OPTION I PAGE*-lENGtH = 56, 

OaTE “ 8 /U /78 I 

Computer •» nssc-i • 

EONylNyATlClN a NO , 

Bound I ns » yes ; 

Err OR ‘■SIZE ® l8 . 
yNDEFlNEo^EYTERNAlS » YES* 

^TST*"®AsE s 8 $ 

SIZE I AOdRESS-Un^It c ifl., 
acgess*untt a 16 ; 

MEHfSlZE = 4096 s 

/• USER OEFtNED TYPES «/ 

type iMOLISt' , 'NoPROc’ $ 

type I'MAJOR', iMiNoRi $ 
tY'PE »0IRECT'. TiNoIPCT* f 
type ilit* $ 

TY'PE tCONTRoL-GCyNTER' , 'fiCV' S 

/•local And GlOBAl vARtABLC OEFInSTIoNS •/ 

O^FauLt mnemonic »DArA« ; ' moNE'S 

LOGAU ’ANSWER' • 0 S 

lOgaL ’DEF* a 1 S 

L°GAL 'EXTErnL' ■ 0 s 

L0GA1 ’INDIPECT* BBS 

lOgAL ’LIT’^ELAG' » 

SEgT I 0N*-S.A Ye ’ , * location ►SAVE ' * 
'LItERA'L*»SgAN'* B 0 * 

' OOLI AR*SeC ' I • 00 L'LiR*L 0 e ’ s 
'MaCR.O*-lImE’ « 0 s 
' BUI.lq' $ 

*FIRst««cArC» a 1 S 
’LABEL*-FliELD’ S 
’STRING’ $ 

'MS’ $ 

’Ml' s 
’PS’ s 
•PL’ s 

'STANDARD' = ii *ShUREE*-LlBRARV’ B 2. 
'^ePeat^arRaY' « 3 ; »magro-expaNQ» a 4» 
'LITERALBPOOL' n lOCF^LlT^POOLI a 6 S 
’NORMAL’ B 1» ’Skip’ a 2, 'REPfAUFJILL* ■ 3* 
’MaGR;0-8UiI.O* » 4 J 


GLObaL 

global 

gLoraL 

GLOBAL' 

global 

global 

GLORiAL 

global 

global 

global 

global 


global 


/• USER Defined sLhanTIc functions ®/ 

sEMANfie ’OrFLABEL’ } 


assembly Language definition (aildef) 


17-1PR-79 


16143 page 


2 


IF (PR'ESfNT (OpER'AniO'Ci ) j ) , 

IF tSvHBOL-TyPE<f)pEBAND<l> ) . £ 0 . UNOEFINED > . 
Else > 

error ( 35 ) . 

END, 

eREATr.-SY'MBDL < OPERANO ri) ) , 

IF fEyrERNL.FQ,!). 

eRiFATE'RErOEFCfjppRAM'DU) ,DEF), 

END, 


ENB J 

semantic 'HaJOP' » 

Blt‘LE,NGrH = 18, 

DEF,L*^EL <OPePAND< 1 ) ) , 

OBjECT( AodreSs*- type (lOg ATI ON»>COUNTER) i 
FfELOf0>5)=OpGOnE, 

F IELn<5f5)nlNnlRECT, 

^ FieLdC6J17)«0pEranDI2) ) S 

semantic ’MtNOP* 1 

Blf’‘LEN®l'Hei8, 

oeflabeL( opeRano-{i) ) ; 

OBJECT < AnoRcSSt- TYPE (LOS AT 1 ON^GOUNTeR ) , 

^IEL0T0>ll)»0,FiELotl2U7)siOPGODE) 
sEm'Antic 'orgsem* ; 

answer = VALUE (DPERANDni in . 

If (ANSWER. 

SECTIoNt 'O aTa'I, 

ELSE, 

IF (An'SWeR.Eq.i), 

SECT I ON ( 'CODE' ), 

Else, 

fail, 

END, 

END, 

SEt-OR ICi {oPEHANO ( tiZ j , * ) $ 


s 


/• SPEOIAl KInO'S of DEfifjiTIoNS */ 

GROuP BEGIN sYMS'DI, '(’ I 

cRouP END Symbol $ 

eNq Statement sTmbol '.poi'.r s 

END module symbol ’DnD' j SEmAnTIC ■ EN 0»M0 DUlE» 

S OURCE-MODE«DEF»'L I TopOOL 


I NStRiUC T ION' , M Ae:RO , . cALl ' 

opeRano(i) e optional 

0FE'RaN0(2j 

SEHANTie • 


„ - . ABEL term, 

a STmB'iL tern LIST, 

OEeL ADeL { fiPpR and ( 1 ) J , 
STaGk*PaRm ( Of’ERA'ND { 2 ) ) 
MaGr.D^LInE.eI $ 


$ 


/• directive AnD PSEuOO op DEFINITIONS •/ 

OlREetlVE 'DATA' I 

OPeRAND(j) * optional label TERM, 


B-4 


assembly LANttUA'CE DEFlNUTlON UlLDEF) 


17-APR-79 


l«<i43 PAGE 3 


0PeRAND‘<2) b any expression LIST. 
semantic b DEFU'BELTnPERA'NBim, 

CREATE^D'AfA(*iOPERANO'(2J| S 
UNLABELED OiRECttvE 'aSSFMrUE' I 
OPERANrod) B AQORESS term, 
semantic b STaRT(OpERaNO( 1) >, 
SEeTloN.< 'DATA'), 

SET‘«Ll TpRAL*'POOU 'DATAI ) , 
SOljRCgi-MODEiSTA'NQARD S 


DiRECtlVE 'RES' 

OPE'RANp(i) p OPTIONAL LABEL TERM, 

OPeRAND><2) b any rXPRrsSloN, 

semanti c b DEFLaBEL'(OPERANDi(1) ) , 

RESERVE I QpERAND { g ),*,*) J 

diRecTtve "Erau’ i 

0PERANDfl)?L*3^L Term I 

OPERAND! ?ANy EXPRESS lONi, 

semantics •: 

SEFL ABELiOPER ANDY 1 j ) ,,E QUATE ( OPERAND (1 ) , OPER AND'< 2 ) , I } 
UNlaBCLEO D]REcTiVE 'lit' 5 

BPERANo.(t> B value EXPRESSION:# 
semantic b aNSWeRsoPpRANDCi) ,mod.z» 

I'F tANSwER.EQ,„0>, 

SET*-LjtERAL*-P0OL! 'DATA''), 

ELSE, 

ip UNsHERiEO.l), 

set;l 1 teral-pool ( 'code ' > , 

Else, 

Fili'. 

ElVD , 

END $ 

uNlabeleo Directive 'Pagei i 
SEMANTIC a EJECTbPaCe $ 
uNlabeled Directive 'lisTi i 

SEM ANTliC M: lISTiNCbI; PR I NT U) % 
uNlabeled directive 'Unl'si i 

SEM^ANTl G B lISTiNCbB; PRINT (0) S 
DIRECTIVE 'PROG' J 

OPCRAND’<l)oL*aEL tERM:, 

SEMANTIC B pRoCESs-MoOicBSKlP S 
uNlabeleo directive 'Eno' i 
semantic . IE {PRDcESS'-hODE ,EQ. SKIP)# 
pRoGESSiMoOc ■ NORMAL, 

ELSEi 

F*1L, 

ENO S 


uNlabeled oirecTtve "Peno* i 

SEmANT ic B If ( SOURGEiMBDE . EQ , M'ACRO-EXPANO ) , 
END-MAgRo, 

SOURGE.MbDEoSTANOARO, 

NA'OROp.L InEii 0:| 


• ••«•••••• warning 

END REOEPINCD AS ANOTHER WORD KINO 


5 


ASS[.M0lY LANCUaCE: OErlNlTloN (ALLDEF) 


17-4PR-79 


16143 PACE 


4 


ro 

tn 


fuse. 

Fail, 
eNq s 

uNla'Beleo Directive -aorgi i 

QPrRANDtl) s aNY expression lIst, 
semantic = IF CSYHnoL^TyRf.(OPFRANO(lil))..EO. absolute. AND. 

SYHHDLHTyPE(0PERA'ND(l,2)) ,£0 , absolute ), 
0RGSEM<nPEHAN3(.l>), 

Else. 

fAlU. 

fnd s 

uNlabfled Directive ’Rorc» i 
OPpHiNOd) . aNY EXPRESS! on LIST, 

SEhAnTiG » IF (sVMBfrL-TYpElQPERANDd.DJ.EO, ABSOLUTE), 

ORcSfM{OPERAN0{1>), 

ELSE, 

fail: 

end S 

ERRoR message : 
number a 3&, 

lEvEl = 1» 

(DUPLICATE L*bEL' S 


fRROR message : 

L ■ 1» 

N ■ 2? , 

•illegal control 


sect I hN I s 


nOun •$' : 

PESULTnADoRESS !ERh, 

semantic a iF {SUerlrLD.EO.OPERAND-riELD) , 

I F < S oUrCE-MOOE . EO ,L I ter AL^POOL . OR. 
SOuRCE»‘MOOe,EO.OEF-L IT*-P00LJ , 
SE r T 1 0 N* S A V E »C T L ► SEC TiON , 

L Or A T I ON» S A VE 6 l OC A T I ON , 

G T i,' * S E G T I On»,D GL L AR* 3E C * 
LOrATlONBOOLLAR'-LOG, 
REfURNTLOGATlON) , 
LOGATlONaLOGATlOWASAVE, 
GTj*-SE^TiON"SECT ION^SAVe* 

ELSE. 

return {LOGaTIOnJ . 

ENiT. 

else. 

FAIL. 
end s 

[NStRiIjCTIoN ’NONe' I 

operand (1> P CONTrOl-CQUNTER s 

instruction 'NONE'! 

OPERAND!!) a optional L'ABEL TERM, 

SEhANTiG a oEFLABEL(QPrRAND!l)) S 


••••*••••• WARNTNt; •*•• 
NO SEMANTICS SPECIFIED 



assembly LANSUAGE DEFINIITION (ALLDEF) 


/• executable instruction definitions •/ 

instruction "FlP' • 
result ■ mTNOS* 

OPEHA'N0<i) a optional l'A'BEL term, 
semantic a oPGODEao'82» , 

rjllNnp<OpERA'NOTl> ) S 
instruction iloO' ; 
result a H-lNOPr 
OPeRANbCi) • oPTICiNA'L i'ABEL TERM, 
semantic b 0PCO0Ea0’i3». 

mINOPTQpEMnO< 1> > s 
instruction ,L0P' : 
result a hINQR, 

OPeRANDTi) d optional I.ABEU TERM, 
semantic 8 0Pc00EtC'i2», 

H INOpTOpErAnOiU) ) s 
instruction ,neC, ; 
result . minor. 

OPcRANO(i) q optional i.ABEL TERHi, 

semantic , oPCDdEso*04», 

M INOP < OpEMnO'< 1 > J s 

instruction ,ADC’ 5 
result q HiNOR, 

OPtRANO'd) q optional lA'BEL TERMi, 
semantic b OPCODEaO'tt**, 

H ‘'NOpIOpErAnDU) > s 
instruction 'CmP' ; 
result q Ml-NOR, 

OPCRANO'dJ « OPTIONAL l'ABEU TERM., 

semantic q OPCOoEeo’lBd 

MlNOoTOpERANDa)) S 
instruction »ndRm’ « 
result a kInOR-. 

OPERAND'(i) c optional i'ABEL TERM, 

SEMANTiG a oPGOsE«o*!j;‘>'. 

H 1 NOpf OPERAND «D ) 5 
INSTRUCTION 'AC)*’ ’• 
rEsUlT 3 minor. 

OPERANDilj q OPTIONAL i'ABEL TERM. 

semantic q QPe 00 E=Q’ 25 », 

MiNOpt operand d)) s 
instruction »Xa*’ : 

result q hInOP. 

OPeRANOli) a optional i'ABEL TERM., 

semantic b GPC0aE=n'25* . 

mI'nop (Operand d) > s 
instruction 'AEA' : 
result » h*nOr. 

OPtRANDfi) B OPTIONAL i'ABEL TERM, 
SEMANTIC B 0Pc00E»0'2B*, 

HliNOp(OpEPANO'tl>) S 
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03 

I 


S0 

^ :S , 


if^'SHucTioN ’xaE’ : 

RtSULT r ’tlNO". 

Of’RRAND(l) s oRTIoWAl LABEL TERM, 
semantic s i.RcO,;iErn ' 26 t , 

mINO«<0pErANO(1>) I 
iNSt-;uC I ION »eaX' : 

result = mIN'QL. 

SEM^.Vlfc^’ " TERM. 


E r;HcOoE = n '?7 I , 

,S*Nnp(OpEtiANiD(l) ) S 

ReV'ERSE-Eax’ ; 

s »llNO^, 

nr>ERANO(i) r optional i’ABEL TERM, 
semantic a ;)RcO.-|:E = o ' ?7t , 

MiNO^(OpEpANDIl) ) $ 
NlT' ; 
s M t NO, I , 


iNSTrfUCriQN 
RaSUL t 


instruction 
result 


## ■■ 

instruction I 
result 

nl’ERANoli) 

semantic 


instruction , 

RESULT 


ORL-HANDCi) s oRTIoNA). label term, 

SfcHANTie s f RcOoE = fl 'cill I , 

• ^f-'lNM.'tOpEsA'NOd) ) S 

INST'RuGTION ,N0p, ; 

RESULT 5 MIN0R> 

' optional i'ABEL TERM, 
semantic c oPCD 0 E=o’p 2 ' , 

,, , .-iINORTOpErAmOII) ) $ 

instruction .EXir' I 
result 3 mInOr, 
operand ti>' s optional [’ABEL TERM, 
semantic a 0Pc0':xE = o'i6I , 

kInD" TQpErAnOU) ) s 
instruction >toV' : 

result a minor, 

OPERANo(i) 8 O'PTIoNal I'abeL term, 
seh-antig a oPcO;oE=n'^i'. 

- KlNOPtOpERANOd)) S 

instruction ,TAP. ; 
result 3 MINOR, 

o’PeRanb<ii = optional Label term, 
semantic a 0PG0uE=0'o3i, 

mINOp IOpEr AnO U) ) i 
TqP' : 
s MINOh, 

3 yPTloNAi i'AB.EL TERM, 

, nPCQoE = o'ci5', 

MINOR lOpEpAMDdM S 
RoV. : 

3 MlNOri, 

0PeRANO(|) a optional LABEL TERM, 
semantic 3 C,PcO[)'E*ri'f!71, 

. mJ'N0P«0pErAwD(1) > s 

instruction 'CPO' ■ 

result . mIM0r» 

OPER'ANO(i) B optional L'ASEL T£RM, 
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CD 

DO 


c SEhAHTIC • oPe00E8D'l7l, 

hInOP(0pERAND< 13 ) s 

rNstKiienoN »siO' •. 

C RESULT « minor, 

OPfR'ANO'fi) » optional LABEi TERM. 

semantic II QPcOoEso' SB ' , 

C H inOp (Operand ( 13 ) s 

iNStROCTION ,TA>a- J 



result ^ 

mInOr, 

V. 

OPPRaND(i3 s 

optional Label term. 


SEHA N T I G a 

OPCOoEai) ' ji r . 



MINOp(0pErAnO<(13 3 S 

c 

instruction »ReD. ■ 


RESULT a 

MINOR. 


operand <1 3 a 

optional Label term. 

A 

semantic a 

gPGOdE=0'?3i , 


mINOP(OpErAnO{13 ) S 
instruction ,riO, : 

( RESULT a mINOr, 

OPeRA'NDIi) a OPTIONAL LABEL TERM, 
semantic a oPcOOEbO'M*, 

C M.|NOP(OpErAnO'(13) $ 

instruction *TiX. : 
iRESULT a minor, 

r- OPcR'ANOTj) a OPTIONAL LABEL TERM. 

SEMANTIC a oPcOoEao ' 11 ' , 

HlNOp(iOpERANDti)} S 
r instruction ,TiE» ; 

result a MINOR, 

OPCRA'Nd(i) a OPTIONAL LABEL TERM. 

C SEMANTiG a OPcOoE«o'i 5 ', 

MINOP<OpErANDU3 ) S 

N°UN It' t 

C: semantic a IF (sUBp JjfLD .EQ. OpCOOE*Pi£LD,J , 

InOIrEoTbI, 

ELSE, 

r- Fail, 

enq $ 

instruction >loA‘ j 
r result a major, ■ 

OPCfl:AND(l3 a OPTIONAL LABEL TERM, 

OPCRANO'I?) a any expression, 

C SEMANTIG a OPCODE »o ' j0 > , 

ha jGp (O perand ( i 3 , operand 12 > 3 s 
instruction 'LOL* : 

C result a m*jOR» 

OPE'RANORij a oPTIONAl i'ABEL TERM, 

OPeRAND {23 » aNY expression, 

C SEMANTIC a OPCOoEan ' 40 » , 

mA jOp (OpERANOn 3 i 0 PERAN 0 '{ 2 ) ) S 

iNsfRliCTION iLOJ' t 

r RESULT a MAJOR. 

opcrand(i> a optional Label term. 
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03 

cb 


V 


OPfHANDt?) e a'^Y expression, 

SEM'-ANTie a oPC0oE=o'l2i , 

H:AJ0:p(0pErAN0<1) iOPERANO'(.2» ) 
instruction 'LhE' i 

result = ■ 

GPeRAN0(i) = optional i’arel term, 

0I-ERAND(2) 3 aNY expression, 
semantic b oPcOr)E = n ' 52 I , 

nAjOptopERANO(l)iOPERANO{2) ) 
instruction 'LdX' : 

RESULT , pAjOK, 

OrTRANOfl) 8 rPTlONA|_ j'ABEL TERH. 
0PfRAND'<2) n aNy expression, 

SEMANTIC 3 oPcODEsifi 'g4 t , 

MA JOp( OPERAND (1) I operand 12 J ) 
instruction ’sta' ; 

RESULT 3 major, 

OPfRANO(i) b oPTl'jNAiL i’ABEl. TERM, 
OPrRANo<2) 3 aNY expression, 

SEMANTIC X nPCOoEso'ftBI , 

MAjOptOpERANDTl) , operand ( 2 ) ) 

instruction 'STI' ! 

result a hAjOR, 

OPERANO(J) a oPTloNAi i'AREL TERM, 
0 PeRAN 0(2> a aNY expression, 
semantic 3 OPC0DEBn’32' , 

„ . M*jD'’tOpElRANOM),.oPERANO!(2n 

INSTRUCTION ,STEt ! 

RESULT a mAjOt<, 

OPERANDT]) b optional i'AREL TERM, 

OPeRANOTs) « a'^T expression, 
sEm An t I c e cP’coqe =o ' 1 0 • , 

MAjQP( 0 pEfiAND'U), 0 PERAND{ 2 ) ) 
INSTRUCTION 'STX> : 

RLSULT 3 major, 

operand Ii> 3 optional I'AREL TERM, 

OPfRANOTB) 3 aNY expression, 

SEh'ANTiG a 0PC:00Exf,'74l , 

ma jop ( O perand U) f operand (2 > j 
instruction 'adX' : 
result s mAjOR. 

OPERANO(i) a oPTlQNAi' i'AREL TERM. 
0PEHAN0(2) b aNY expression, 
semantic 6 0PCOdE = 0 ' !>2 • , 

H A joi> I Operand ( 1 ) , operand ( 2 ) > 
instruction 'ADD' ! 

REsUlT * pAjo,^, 

OMERANdii) 3 optional i'ABEL TERM, 
operand ( j) a any EXPRESSION, 

semantic a qPCOdEeo'ijA', 

HAjOp<DpERANDU),OPERANO(2n 
instruction ,SuB' : 
result a major. 


$ 


s 


s 


s 


s 


s 


s 


$ 


s 


CD 

O 


O O 

•n 2 

o 

o s 
o > 

53 ?“ 

O ‘O 
e > 
> o 

c ^ 

H _ 

S < 4® 


; C 

o 

OPpRANDti) 

OPPRANOT?) 

c 

semantic 

instruction f 
result 

■ o 

OPERANO(i) 

operand (2) 
semantic 

i o 

f 

iNSTRtjCTlON *'E 

o 

result 

OP tRANO'1 1 ) 
operand (2) 
semantic 

c 


c 


assembly LANCUaCE definition (ALLOEn 


m opcode =0 ' 24 t , 

MAjOp(OpE9ANOiU.)iOPERaNO(2)) S 

nUU * I 

* M'A jOfi, 

B Optional I.'abei, term. 

» a‘Ny expression,, 

» OPCOoEao *^4 r , 

)I * * ^ >» operand 12) ) s 

» h'^jOr. 

■ OPTIONAL' Label term, 

« any expression., 

• OPGODEooIj^,, 

i nstruct ion , ‘ op^pano ( 1 ) , operand (2 > ) s 

PfSULT a mAjOH, 

®peP'ANo(1) b oPtionaI' Label term. 

OPePaNO<2> » aNY express I ONi, 

SEMANTie 8 CPcO0E*o'20t, 

instruction ,*,^o'7*f®'’‘°P^P*NOU),oPERANOi(.2n s 

RESULT , major, 

fiPERANo(j) B optional Label term 

0 PfRAND( 2 ) p any EXpiE^sfoN, * 

» oPGDOEan*20l , 

MA JOP ( OPERAND ( 1 ) , OPERaNOiIS ) ) S 
MRC ’ « 
a major, 

. optional label term. 

a aNY expression., 

B oPCOoEbb«50I , 

^^fMAjOp(OpE|,ANDd>,oPERANOi{2)) S 
B major, . 

■ '>NEL term. 

a aNY expression, 

B cPCooEsQijai ^ 

B hAjOr, 

” i term, 

B any expression, 

B GPCOOEsgt70i, 

jOp f OrEr ANO ii > , operandie ) ) % 

B majop, 

tepm, 

express I ON, 
sEm Antic a oPGODE«o'i6t, 

I«SfROCT.O» , 
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o 

SEmAnTiC 

instruction » 

O 

result 

operand ( i> 
0 PeRaN0{2> 



semantic 

«Av, 

instruction •! 

■o 

•V * 

result 

operand ( i) 

OPeRANO(2) 


c 

semantic 


instruction *e 

r" 

K 

RESULT 

operand (j ) 
OPER'ANO'I 2 ) 


o 

SEmAnTiC 


instruction tQ 

o 

RESULT 

OPE'RAND(j^) 


o 


u-a 
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result 3 

f|.?EHAND(i ) a O^Tl :iN*|_ i‘AREL TERM, 

QPfRANrK?) a 4ny expression, 

SEmALTiG a 0PeQ0E=n't6', 

rAjOt.'(OpERAA'oU> , 0 PER:A'NQi( 2 ) ) S 
INSTMiCTIoN iShF. : 
result o mAjOr, 

OPF'HANOCi) a nPTlONAt I'ABEl. TERM, 

0PpRAN0<?) 0 aNY EXPREsSlJfl, 

SEh^NTjC a oPG0DE=o’H' • 

M*JOt>{0:pERAADU) rOPERANO'(2) ) $ 

instruction -OSH’ : 
result a major, 

OPERAND(i) a optional I ABEL TERM, 

OPERANDtp) a aNv EXprEsSIoN' 

: sekanTig b oPcooE=n' 36 i , 

M'A J 0 p < 0 P E R AN 0 { 1 ) , 0 PE R A N 0 ( 2 ) ) 'I 
iN'STRueUON ■og'i'' : 

REsU( T = mAjOR, 

OPERaNO(I) 0 ::PTjONAL LABEL TERM, 

OPERAND ! 2) = ANY E VPRlSS I ON . 

semantic = OPCoDf • O’ 56’, 

MAjOpTOPERANDIi) ,0PERAND(2) > 5 

iNSTRueTlON 'GYC : 
result a t-AjD,!, 

OPFRaNQ(t) a optional i'AiBEL TERM, 

OF’FRANOfgJ a any expression, 

. semantic a OPcOoE = o ' 3 A t , 

p A jOp t OpErANO $ 1 ) , oPER AmQ 1 2 ) ) S 
instruction ,B:RM, . 

RESI'FLT a hAJO«, 

OPERANDCd a oPtI-iNAi i'abel term, 

OPpRANotj) a aNY ^^.XPresSIuN, 
i SEhAN Ti C a oPCDDEafu < 0l6 ( . 

M A j 0 o < 0 p E R A N 0 a ) , G P E R AN D'l 2 H S 

instruction >0RiU' : 
i RES'ULT a mAjQ,{, 

OPERANOTi) a optional i'ABEL TERM, 

OPFRANDI?) b aNY expression, 

T SEh'AnTIC s OPCODE-q ' a2 I , 

MAj:Gp{OpEBAND{l> ,OPERaN0:{2) ) S 

instruction '0iRG' : 

? result a mAjOr, 

OPERAND! 1) a oPTInNA, i'ABEL TERM, 

OPERAND!?) a aNY EXPRESSION, 

S'EMANTi e a OPCOoEof) ' ’ , 

HAj0p(.0pEBAND(i),OPERANDi2) ) $ 
instruction ’TiN' ! 

( RESULT a mAjOR, 

OPeRANoIt) a oP'iloNAr i'ABEL TERM, 

OPCRANO:!?) a aNY eXPrEsSION, 

SEMANTiC B qPgOdE = 0 ’ 72 * , 

hAj.Op(OpErANO(1) •operand 12 ) J s 


I UtFJNIIION 
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instruction 'TXLE' « 

RESULT 8 mAjORi 

OPERANO<l) a optional L'ABEL TErR, 

0PERANQ(2) a any EXPRESSION. 

SEMANTIC a OPCOoEaf) ' 22 ' , 

MAj0p{0pERA(gD(l)»GPERAND{2) ) S 
instruction itau* : 

RESULT a M'AjO«?r 

OPCRANOCi) a optional L'A0E.L TERM, 

oppRANQip) , any Expression,, 

SEm'ANTiC a oPGDOEafi ' r6» , 

HAjOp(OpEbA'ND(1J .0PERaNQ{2) » S 
instruct 10.. 'TaC : 
result a major, 
operand < l) * optional label term, 

OPCRANOIjl a any EXPRESSION, 

semantic a oPcOoEafl'Afi' , 

M'A JDP f OpErA'nOM 7 oPER A'NO'I 2 ) > * 
I'NstRUGTION .TA'S, t 
result a mAjOf?, 

OPtRANo(i) a optional lAPEU TERM, 

OPEliANOCa) a aNY eXPrEsSION, 

SEMANTIC a oPcOdEbo ' 66 i , 

M*jOP(OpERANQ tl) j0PERAN0i(2n S 

/• sYmBol Opr i-nIt Ions Tq support AssEi^aLV •/ 


pNEFlx operator 


result 
OPCRANO<i) 

semantic 


, t ' ; 

A NY expression# 

LlT, 

aNSWCRscHpCKoP < KINO ,1 ) • 

Jp ( answer , EQ 1 1 NS TRUCT I ON . OR , Af ,SHER . EO , 0 1 RECTI VI > , 
1 1 TE rAL' < ♦ D A T A ' , OPE RA NO < 1 ) # , L I T *rL A C ) , 
RETUrnIoPERAnD(I) 1 , 

else. 

Fail: 

EN0 s 


WARN INC 


pREFjX operator ’*<' • 

result 1 cONTROLfChUNTER, 
precedence a 10# 

operand ( l) a CGV» 

SEMANT le 8 aNSWeRb value I operand ( 1 > 3 , 

iF (answer. EQ,0), 

SeGTiOmi IDATA' ) , 
else. 


PRECEDENCE NOT SPECIFIIO 23 USED 


IF (answer I E 0,1>, 
S^GTlON'CeODEN, 
ElSe . 

ERROR (293, 

F A 1 L , 


End# 
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i;N0 s 

postMx QpepatoB I 
result a CCV» 

Of■EKA^O(l) a any EXPr£sS1oW, 

SEMANTIG 3 if (CHEcKinP fSPELLlNG.l) .tQ, *$( 1 ) , 

PETURNfOPERAND'd)). 

ELSE, 

pajl; 

END $ 


[Nfix OPERATOR '.'I 

RESULT a I AbEu TrRH, 

PRECEDENCE * 

OPERANO«iJ s cOnTrol*counter, 
operand ( 2) s lA'BEl Te:Rm, 
semantic 3 RETUrNIoPeRanDIJ) ) 5 
pOstMx QpLkAtob I 
result a lUi 

nPEPAND<t) 3 sYmBjL TERM, 

SEMANTIC . RETURN{QPpR.A,NO{l) ) j 


pOSTFiX operator ( 

result . lA^bEL Te;Hm, 

OPERAnDId 3 TEHu. 

semantic 3 externlbi; 

return (operand ( 1 J ) s 



iNfiX operator I 

result s aNY expression, 
nPERANO(t) e ANY EXPRESSION, 

DPERAND(5) b any expression, 
precedence s At3, 

result t aNy express t ON-, 
OPfRANOti) a any eXPrErSION, 

orrRANfjt^) 0 any expression, 
pnFCEOENcE e A'U, 


SLMANIIG e 

prefix operator 
result o 

OPiERANO (i ) a 

PREGEDENcE c 
SEMAMTiG e 

prefix operator 

rLsUlT 8 

operand ti> a 

precedence a 
semantic a 

infix operator ' 


RE TUhN{ oPrR and ( 1 > -operand ( 2 J J 

any expression, 
any expression, 

4-B, 

rETUrNCoPsRaNDTi) )$ 

1^1 ■ 

ANY expression* 

aN’Y expression, 

Aitf, 

fiETURN(f!-fiPERANO(i3 ;S 

• ' t 


s 


$ 


c:.usk^\ 
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^•••••••aa warning 

precedence not specified 1000 USED 


•*•*••••“* warning 

PRECEDENCE NOT SPECIFIED 1000 USED 


•*•••••**• WARNING » »AaV Tr L a« 

precedence not SP_ECTFIeo 1000 USED 
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* aN'Y EX'PfiEsSIDN, 

« any expression,, 

« a NY express I ON:, 

s '0, 

I nPpRANO 1 1 ) oOPER'ANOO) >s 

» any expression,, 

B aNY expression., 

B any expression, 

» 5», 

» return (ciPpft and <iJ /operand (2 ) >s 

i { 

• ANY expression, 

9 any expression, 

■ aNY expression, 

e 2«, 

0 ^ RE TUrN'I qPrRanO 1 1 ) , XOR . OPER-A NO'I2 ) >5 
« any expression, 

« ANY expression, 

• any expression, 

* 1*'' 

* r ’’ ANO < 1 ) . GT , OPEBAND'1 2 > ) $ 

» ANY expression, 

? any expression, 

» aNY expression, 

• 1^, 

= turn ( oPr R Ar|0 ( 1 > ,(_t . oPERA,^D,{:2 > ) $ 

’’ I 

B any expression, 

B any expression,. 

B any expression,, 

B , 

• return, ( OPPR, and ( 1 ) . EQ . OPEHANOIC 2 J ) 3 

I 

, aNY expression, 

B any expression, 

8 A'NY EXPRERSlONi, 

’ 

1 rE turn ( VSwL , { OPERA NO ( i ) , OPER-ANDI 2 J ) )S 

* o* • 5 

« any expression., 

? any express ';oN,, 

, any expression, 

I 6“, 

' » and ( t J *1 10 bbOPER aND 1 2 ) J > $ 

> ANY expression, 

> any expression.,. 

I aNV expression, 

I 6-0, 

I RETUrN (oPpRAnO(1) /10»bOPERAnO'<3) is 
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infix operator 'o'" ! 

result 3 any EX-’^rEsSION. 

nP:E*TAN0(i) = any express I mN,, 
nf’FPA:N0(2) 3 aN'Y "XPrEjjSIGN:. 

pftECEOENcE s 3'«. 

SEMANTIC s RETURN(Qpi:RAND<l) , AN0.0PERA'N0'(2) >$ 
infix opera roR U*> : 

result _ any expression, 

OPfRANoT,) 3 aNY tXpRESSlUN, 

OPfRANoI?) , aNY EXPRESSION:, 

precedence a 2H, 

semantic a REtUrN(qPcRanD{ 1) .OR.oPERAN0i|2))S 

infix operator 'o/-* I ■ 

result „ any expression, 

OPERAnOIi) b any EXppEss 1|)N-I 
gpeRand<?)s A'my Expression* 
precedence 6 W, 

SEmANTIG e ft^ETURNIV.SiijR.lOPERAMDIiI.OPERANDianU 

infix operator 

REsUlT b S^mDoL tErh uJST* 

DPERANQ(i) s sYmRoL term list," 

OPERaNOC?) s sYMSuL tE:|M, 

PRiECEOENcE b 1‘<T, 

SEmAnTiC b LlSTF<0pE|iiANGil)*OPERANO<2>) $ 

infix operator t,' I 

RESULT s aNY EXPRESSION LIST, 

OPERaNdIi) 3 aNY expression list, 

0PERAND<21 b aNY EXPRESSION:, 

PRECEBENCE a I'd, 

semantic b LlSTF(0p:ER:AN0a)iGPER.ANB(2)) S 
END OF AulOEP O’EfInItIOm J 


. Q 'C/ 

J3j 




assembly LA'NOUASE definition IALLDEF) 


17-APR-79 16|AJ pace 


ToTaL number of RECOSNlTiGN ERRORS * B 



Appendix C 

ALLLEX NSSC-I DEFINITION 


C-T 


uex:cal token definition 


17 -APR -79 


16I49PAGE 


o 

ro 


r- 


c 

c 


o 

c 


BEOIN LEXIG'Ai, definition $ 

<LFXieoN> :» 

IF riRsT^GARQ N[t n, 

<f I RST gArD> 

IF macros EO 0 
// <MArROpREPASs>, 

MACrOS»-0, 

CURSOR'*! 

] > 

!F SUBriEuD LE FIELOS. 

I 

IF NOT * 

IF not ' , ' , 

<token>i ■■ 

{ 

MnEhONIC EQ 0, ,, „ 

TOkIN^sTArTbPOSITION of <token>, 
TOkEN‘SIZe«ij*12£ of <T0K'EN> 
nuLl 

) 

If subfIeLo eo i, 
scan. 

( 

GijRsOR»LENf.T|4 
O IF eCRSoRfCHiR £0 -999 

HNEHONie'2, 

Token"! ype«nahe; 

SwBFIFlDs? ' 
it SCAfj,, 

( 

CURsOrPLEnCTh 
ft IF GtlRSOB-CHAR EQ -999 
ft SUBFlEtDffSUBFlirUO*! 

) t 

<LEy IC0N> 

\ 

tt GuRSOrt»LENi*TH, 


/• CHECK FOR ASSEMBLE CARD */ 


/* IS A MACRO PASS NEEDED 

/•OCT all macros 


/* UNTIL all FIELDS 

/• NEXT FIElO if blank OR 
th comment 
/* get a token 


t* only For actur^ 


/* CHECK FOR null line 


*/ 

*/ 


•/ 

*/ 

•/ 

•/ 

*/ 


•/ 


/• get next field 

f* IGNORE REST IF COMMENT 

/• OR REACHED END OF LINE 
/• REaGHEO next FIELD 

/• conjINde hith nEh token •/ 


*/ 

•/ 

*/ 

*/ 


42 

_ ToK'ENi*-TypE«ENO*>OF*»LrNE S 

<TOkeN> tP • 

i’F SOUftcE-MoOE r.Q mAgRO*EXPAND. 
jF MACro-linE Sa 0 i 
JF SuBpielD Eq 3, 

<MA'EROARG>:f 
?OKEN*-tYPE»SYMBdL 
tt If prqcess"mQoe eq sgip, 
<SkIpmACPoTeKT> 

// If LlTpRAL^SCAN £0 i* 
<2£R0LeV'ElPaREN>» 


/• JUST GET OyT If TOO 
/• MANY fields 


/• PARAMETER SUBSTITUTION 
/* MUST be first line 
/• IN argument field 
/• return as a symbol 

/* IGNORE TEXT OF MACRO 
/• PARSE LITERAL 


•/ 

• / 


•/ 

*y 

•/ 

4 / 


•/ 

*/ 
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IEXiCAl token definition 


o 

CO 


% 


ni 


L’l TErAi. fSc A’N ’' :' I 
toK'En*-’ ypt^'S’»',.3oL 
// If letter, 

<N'AME>, 

( 

IF SUBfIeUD EQ 1, 
TOKEN^TYpErtABEL" 

// ToKfn-TYpEsN'A'ME 
1 

// IF 0IG|T, 

CnUHB:eR> 

// IF SPEgIALi 
<SPECI,'.L>, 
token* 1 YPET special 
// IF AlMfRIGi 
<SYMB0|.>, 
tCIKEN*-TYpEPsYHaoE 
// IF Cur.s(jr,.ChAr eq ;9,9 
CURSoR=ELJRS;0Rn, 

. ,, T0KE:N*.TYPE«ENDH!IF4 .:LInE S 

<nOh 0 £r> := 

IF SUbfIEI.D eo z, 

HNEM0NiG=1i 
token* I YPESNAME, 

GURSoRircURSOR-i 

// I 

IF • 0 ' , 

<OCT>, 

TOKEN*VALuEsVAiy£ qF OCTAL <OeT> 
// <INT>, 

f OKEN^vALuEaVAiyE 0 '^ <InT> 

) ) 

TOK'£N*tYPE«vA'LUE s 
<M*GR0,ARG:> In 

1 TO 20 
t 


If not ' r; 

Jr NOT 
GnAr.AcTEr 
} X 

<S«IPMAeRO'TExT> le 
( 

IF SOBFIrs^fi CO U 
<nA'ME>, 

SE A’N I 

SuBFIeLDbS 
// NULL 

>* 

{ 

If SUbFIci .5 EQ z, 

If OURSQR*eHAR NE - 999 , 
If not *cNn t, 
GU«SOr.«LcNbTR, 


/* CHECK FOR A name */ 

/* IS THIS A label »/ 

/* NO, JUST A NAME */ 

/• CHECK for a number •/ 

/* check FOR SPECIALS •/ 

/'• unknohn symbol •/ 

/* EN0 oF line Token •/ 


/• A LEADING 0 means OCTAL */ 
/* IF NOT THEN decimal */ 


r 


UEUlCAL fOKCN OEriNlTlON 
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is 




MnEMOnIGoS: 

toK£:n>typEbN'ahe 

If SUbFIgLd NE 2 


// 

) s 

<sYmboL> 

^ AlMERICS s 

<1NT> I a 

t TO Ig Ol'ClTs S 
<0CT> i« 

1 TO 12 OCTAtS S 

<NAME> ja 

i TO 8 LETMERICS s 
< SP£:e iAL.> I a 
( 

< 

«♦ ' 

// t-« 

) 

it 

// 

// ’o’ 

it null 
> 

ft •/', 

< 

V 
tt Null 
j 

// »*', 

* « » 

// Null 

j 

tt 

{ 

t „ I 

// NULl. 

) 

tt IT SUBfIElO Eq 1, 

• SC 

tt IF SUfiFlELO Eq z, 


If Image ( Cursor;? j eq a 
ft IF IMACE(euHsOR;2j eQ -11 

) i 

L'l TERAi.’-SGAiNal 

tt SPEClAi s 
<M A'GROisREPASS> I B 


/• letters And/or oicjts •/ 

/• decimal digits */ 

/• octal digits •/ 

/* LETTER and letters oy 

/* ANO/0R digits •/ 


/* A 
/* A 


Shifted lEft n plages 
SHIFTED RIGHT N PLAGES 


*/ 

*/ 


/* 

/* 

/* 

/* 


A multiplied by l0»*N 
A multiplied by 
LOCIGAl and ™ 

multiplication 


•/ 

*/ 

*/ 

*/ 


/* remainder of A/N 
/• DIVISION 


•/ 

*/ 


/• logical or 
/* addition 


/* EXCLDSIVE OR •/ 

/• subtraction */ 

/• control section indicator*/ 


/• 


•null • [,1 rfcK 

left PaREN followed " 


*/ 

•/ 

•/ 


/• A Blank* or 
/* A comma 


/* relational operators etc.*/ 


t-IXiCAL fOKCN DEriNlTlON 


17-APR-79 


t6l45PACE 


4 


eycLc 

t 

GuR'SORal , 

IF CURSQR'-GHaR nE -999, 
Scan, 

{ 

tF G*i<flSoR EQ i; 
<LA'0£l>, 

I ABeUFiiElO=i 
// I ABEi-Fj'E'.O*0 
)• 

scan, 

( 


) > 


•PROG ' , 

<lEG*L*' 

If LAeFl^FlELD EO Ir 
IF S^lLo nE 1, 

MSopOslTlON Of <LA8EL>, 
ml=sIbc or <lAbel>i 

PS=hS, 

pL»Ml, 

ANS wER» S T A'R TmAoRO ( MS , ML . PS , PL i 
p U I L Gs 1 ' 

'EnO’ ,, 

<LEg4:L>, 

TF BUiLD EO 1, 

TF lAbGl<.F1ElQ EQ 0, 

ENO-MiAeRO, 

Bull BsU 

7/ TF bWiLd lO 1, 

CURsOR“1« 

STRiNg^CUrSOr, 

START^aOOy^Ll'NE, 

<:80rLQELEMENTS> 

// NULL 

J, 

NEX7*ImAgE 


RESEt-INPuT. 

3 (NEXT^ ihaGi; ) 5 

< 2 EftOLeVCLPAREN> Jb 

t SCAn foR ''S>, 
ANSkERbLtScAn 
// AnSmER«0 
)/ 

< 

SCAn fpR , 

// SCAfj f oR ’ ) , I 

CURSoRcLTSGaN, 

e IF anshEr gt 0, 

IF answer lT LTsCiN, 
LIT^FlaCbI 


/• until end of Input 
/* check label field 


/• macro definition 

/-* MUST HAVE label FIELD 
/• NESTED NOT ALLOWED 
/«* SAvE macro name 

7 * and Parameter name 

/o EnjO qF mACro 

/* MUST BE IN A MACRO 
/• MUST NOT Have a label 

/* MACRO body 


/* BUILD PIECES Of LINE 


/• re-position input 


*/ 


*/ 


•/ 

*/ 

•/ 

«/ 


•/ 


*/ 

*/ 

*/ 

*/ 

•/ 


•/ 


Lexical token DEFiiNinoN 
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r 


o 

0 ) 


;oQ <: 

§i 


is 


C 




)» 


// UT^FLaC**’ 

r ’ * 

<I.ECAl> ;p 

I * 

// s 

<L*BCL> so 

MS'* almerIcs, 

<By'lLOELEMENTS> |c 

SGANfcF oRfcPARfi, 

if LtSGAn 6t 0., 

CURSoftaLfSCAN, 

{ 

GURsoRsOuRSQRppt:, 

AnSwER«0, 

M 

<M<JH8ER>, 

I ^ “ ''f L '^^"'TOKiENiVALUE*!,, 

ANSkerbI., '■ 

NOT null 

// If answer eQ t, 

<N0wSU8>, 

AN3WER:DSu0PARMNuMij TOKENfVALUE 
CURsORqCuRSORipL', ^ *” 

<NOrbER>, 

StSiNGoCuRsOR 
// CURsoR»GwRSOR*PL 

<BUIlDflEhEnTS> 

// CtlRSORatENCrrt, 

<NONSOr> s 

<N0NSUg> S» 

If STRING Ce cursor 

<FlRSTeARD> :> 

lif^f IRST^CA'RO EO i; 

SCAN. 

SU8F IELD?2» 

|°«|N-SrA'RT.CufrSoR; 

ASSEMBLE' * 

T0K£n«-Si2e«6.i 
TOKEN*>T yPE"N*MEi 
. nRSj*GARD»2 
If. f IRST..CAR0 Eq 2, 

SCA'Nf 

<NA'He>, 


/• BLANK and comment 
are only legal token 

/• MACRO Name is four 
/* LETTERS ANO/OR DIGITS 

/• LOOK ahead for a SuB- 

/• STITUTION 

>'* If IT IS foUND 

MOVE TO THE PARAMETER 

/* HOVE PAST parameter 

/♦ determine parameter 
number 


•/ 

•/ 

•/ 

•/ 

•/ 

•/ 

•/ 

*/ 


•/ 

•/ 


yl NON-SUBSTITuTABLE */ 

/* PART Of THt i i:Wr ay 

/* PUT IN parameter NUMbIr •/ 


/* NOT A parameter, ignore •/ 


A* SCAN OFF Rest of line 

/* AND OUTPUT 

/• N(3 N-sU 8 stItUTABLE CqOE 
/• ONLY PUT OUT IF THERE 


•/ 

•/ 

•/ 

*/ 


n 


^ t 


Le:X]Gal token definition 


' SWeFiELDej.i 

TOkEn-TyPE’NA'ME, 

TOkEn^SiZe»SIhE of <name>, 

^ '^^N>StArT=PoSIj](5N of <N'A‘ME>, 
USTingbI. 

MACR()S»li 
0 TO 2 
( 

SeAN, 

' t 

MnOlIST)', lJsTINGb0 
O ' (NOPROG) MArROS=>0 

) I 

f iRSfCARD"? 

// SCAN, 

IF CuRSoR^GhAiV EO ;999, 
C0RSoR*gUrS0R*1, 

TOK'EN»TyPEA:END*’QF*i’I NEi 
nfiSTfcCAf*0'*'0 S 
end Of lexical OEfINItIOn s 

I 


o 
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o 

00 


r 


uexical token definition 
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r; 
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